polkit

package: polkit

title: polkit(8)

summary: Authorization Manager

text:
# polkit(8)

## NAME
polkit - Authorization Manager

## OVERVIEW
polkit provides an authorization API intended to be used by privileged programs (“MECHANISMS”) offering service to unprivileged programs (“SUBJECTS”) often through some form of inter-process communication mechanism. In this scenario, the mechanism typically treats the subject as untrusted. For every request from a subject, the mechanism needs to determine if the request is authorized or if it should refuse to service the subject. Using the polkit APIs, a mechanism can offload this decision to a trusted party: The polkit authority.

The polkit authority is implemented as an system daemon, polkitd(8), which itself has little privilege as it is running as the polkitd system user. Mechanisms, subjects and authentication agents communicate with the authority using the system message bus.

In addition to acting as an authority, polkit allows users to obtain temporary authorization through authenticating either an administrative user or the owner of the session the client belongs to. This is useful for scenarios where a mechanism needs to verify that the operator of the system really is the user or really is an administrative user.

## SYSTEM ARCHITECTURE
The system architecture of polkit is comprised of the Authority (implemented as a service on the system message bus) and an Authentication Agent per user session (provided and started by the user's graphical environment). Actions are defined by applications. Vendors, sites and system administrators can control authorization policy through Authorization Rules.

[IMAGE][1]

```
 +-------------------+

 |   Authentication  |

 |       Agent       |

 +-------------------+

 | libpolkit-agent-1 |

 +-------------------+

        ^                                  +---------+

        |                                  | Subject |

        +--------------+                   +---------+

                       |                        ^

                       |                        |
User Session           |                        |
=======================|========================|=============
System Context         |                        |

                       |                        |

                       |                    +---+

                       V                    |

                     /------------\         |

                     | System Bus |         |

                     \------------/         |

                       ^        ^           V

                       |        |      +---------------------+

        +--------------+        |      |      Mechanism      |

        |                       |      +---------------------+

        V                       +----> | libpolkit-gobject-1 |
+------------------+                   +---------------------+
|    polkitd(8)    |
+------------------+
| org.freedesktop. |
|    PolicyKit1    |<---------+
+------------------+          |

          ^                   |

          |            +--------------------------------------+

          |            | /usr/share/polkit-1/actions/*.policy |

          |            +--------------------------------------+

          |

   +--------------------------------------+

   | /etc/polkit-1/rules.d/*.rules        |

   | /usr/share/polkit-1/rules.d/*.rules  |

   +--------------------------------------+
```

For convenience, the libpolkit-gobject-1 library wraps the polkit D-Bus API and is usable from any C/C++ program as well as higher-level languages supporting GObjectIntrospection[2] such as JavaScript and Python. A mechanism can also use the D-Bus API or the pkcheck(1) command to check authorizations. The libpolkit-agent-1 library provides an abstraction of the native authentication system, e.g. pam(8) and also facilities for registration and communication with the polkit D-Bus service.

See the developer documentation[3] for more information about writing polkit applications.

## AUTHENTICATION AGENTS
An authentication agent is used to make the user of a session prove that the user of the session really is the user (by authenticating as the user) or an administrative user (by authenticating as an administrator). In order to integrate well with the rest of the user session (e.g. match the look and feel), authentication agents are meant to be provided by the user session that the user uses. For example, an authentication agent may look like this:

[IMAGE][4]

```
+----------------------------------------------------------+
|                                                          |
|  [Icon]  Authentication required                         |
|                                                          |
|          Authentication is required to format INTEL      |
|          SSDSA2MH080G1GC (/dev/sda)                      |
|                                                          |
|          Administrator                                   |
|                                                          |
|          Password: [__________________________________]  |
|                                                          |
| [Cancel]                                  [Authenticate] |
+----------------------------------------------------------+
```

If the system is configured without a root account, it may prompt for a specific user designated as the administrative user:

[IMAGE][5]

```
+----------------------------------------------------------+
|                                                          |
|  [Icon]  Authentication required                         |
|                                                          |
|          Authentication is required to format INTEL      |
|          SSDSA2MH080G1GC (/dev/sda)                      |
|                                                          |
|          [Icon] David Zeuthen                            |
|                                                          |
|          Password: [__________________________________]  |
|                                                          |
| [Cancel]                                  [Authenticate] |
+----------------------------------------------------------+
```

Applications that do not run under a desktop environment (for example, if launched from an ssh(1) login) may not have an authentication agent associated with them. Such applications may use the PolkitAgentTextListener type or the pkttyagent(1) helper so the user can authenticate using a textual interface.

## DECLARING ACTIONS
A mechanism needs to declare a set of actions in order to use polkit. Actions correspond to operations that clients can request the mechanism to carry out and are defined in XML files that the mechanism installs into the /usr/share/polkit-1/actions directory.

polkit actions are namespaced and can only contain the characters "[A-Z][a-z][0-9].-", e.g. ASCII, digits, period and hyphen. Each XML file can contain more than one action but all actions need to be in the same namespace and the file needs to be named after the namespace and have the extension .policy.

The XML file must have the following doctype declaration

```
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE policyconfig PUBLIC "-//freedesktop//DTD polkit Policy Configuration 1.0//EN"
"http://www.freedesktop.org/software/polkit/policyconfig-1.dtd">
```

The policyconfig element must be present exactly once. Elements that can be used inside policyconfig includes:

vendor

The name of the project or vendor that is supplying the actions in the XML document. Optional.

vendor_url

A URL to the project or vendor that is supplying the actions in the XML document. Optional.

icon_name

An icon representing the project or vendor that is supplying the actions in the XML document. The icon name must adhere to the Freedesktop.org Icon Naming Specification[6]. Optional.

action

Declares an action. The action name is specified using the id attribute and can only contain the characters "[A-Z][a-z][0-9].- ", e.g. ASCII, digits, period and hyphen.

Elements that can be used inside action include:

description

A human readable description of the action, e.g. “Install unsigned software”.

message

A human readable message displayed to the user when asking for credentials when authentication is needed, e.g. “Installing unsigned software requires authentication”.

defaults

This element is used to specify implicit authorizations for clients. Elements that can be used inside defaults include: allow_any

Implicit authorizations that apply to any client. Optional.

allow_inactive

Implicit authorizations that apply to clients in inactive sessions on local consoles. Optional.

allow_active

Implicit authorizations that apply to clients in active sessions on local consoles. Optional.

Each of the allow_any, allow_inactive and allow_active elements can contain the following values:

no

Not authorized.

yes

Authorized.

auth_self

Authentication by the owner of the session that the client originates from is required. Note that this is not restrictive enough for most uses on multi-user systems; auth_admin* is generally recommended.

auth_admin

Authentication by an administrative user is required.

auth_self_keep

Like auth_self but the authorization is kept for a brief period (e.g. five minutes). The warning about auth_self above applies likewise.

auth_admin_keep

Like auth_admin but the authorization is kept for a brief period (e.g. five minutes).

annotate

Used for annotating an action with a key/value pair. The key is specified using the key attribute and the value is specified using the value attribute. This element may appear zero or more times. See below for known annotations.

vendor

Used for overriding the vendor on a per-action basis. Optional.

vendor_url

Used for overriding the vendor URL on a per-action basis. Optional.

icon_name

Used for overriding the icon name on a per-action basis. Optional.

For localization, description and message elements may occur multiple times with different xml:lang attributes.

To list installed polkit actions, use the pkaction(1) command.

### Known annotations
The org.freedesktop.policykit.exec.path annotation is used by the pkexec program shipped with polkit - see the pkexec(1) man page for details.

The org.freedesktop.policykit.imply annotation (its value is a string containing a space-separated list of action identifiers) can be used to define meta actions. The way it works is that if a subject is authorized for an action with this annotation, then it is also authorized for any action specified by the annotation. A typical use of this annotation is when defining an UI shell with a single lock button that should unlock multiple actions from distinct mechanisms.

The org.freedesktop.policykit.owner annotation can be used to define a set of users who can query whether a client is authorized to perform this action. If this annotation is not specified, then only root can query whether a client running as a different user is authorized for an action. The value of this annotation is a string containing a space-separated list of PolkitIdentity entries, for example "unix-user:42 unix-user:colord". A typical use of this annotation is for a daemon process that runs as a system user rather than root.

## AUTHORIZATION RULES
polkitd reads .rules files from the /etc/polkit-1/rules.d and /usr/share/polkit-1/rules.d directories by sorting the files in lexical order based on the basename on each file (if there's a tie, files in /etc are processed before files in /usr). For example, for the following four files, the order is

•/etc/polkit-1/rules.d/10-auth.rules

•/usr/share/polkit-1/rules.d/10-auth.rules

•/etc/polkit-1/rules.d/15-auth.rules

•/usr/share/polkit-1/rules.d/20-auth.rules

Both directories are monitored so if a rules file is changed, added or removed, existing rules are purged and all files are read and processed again. Rules files are written in the JavaScript[7] programming language and interface with polkitd through the global polkit object (of type Polkit).

While the JavaScript interpreter used in particular versions of polkit may support non-standard features (such as the let keyword), authorization rules must conform to ECMA-262 edition 5[8] (in other words, the JavaScript interpreter used may change in future versions of polkit).

Authorization rules are intended for two specific audiences

•System Administrators

•Special-purpose Operating Systems / Environments

and those audiences only. In particular, applications, mechanisms and general-purpose operating systems must never include any authorization rules.

### The Polkit type
The following methods are available on the polkit object:

void addRule(polkit.Result function(action, subject) {...});

void addAdminRule(string[] function(action, subject) {...});

void log(string message);

string spawn(string[] argv);

The addRule() method is used for adding a function that may be called whenever an authorization check for action and subject is performed. Functions are called in the order they have been added until one of the functions returns a value. Hence, to add an authorization rule that is processed before other rules, put it in a file in /etc/polkit-1/rules.d with a name that sorts before other rules files, for example 00-early-checks.rules. Each function should return a value from polkit.Result

```
polkit.Result = {

    NO              : "no",

    YES             : "yes",

    AUTH_SELF       : "auth_self",

    AUTH_SELF_KEEP  : "auth_self_keep",

    AUTH_ADMIN      : "auth_admin",

    AUTH_ADMIN_KEEP : "auth_admin_keep",

    NOT_HANDLED     : null
};
```

corresponding to the values that can be used as defaults. If the function returns polkit.Result.NOT_HANDLED, null, undefined or does not return a value at all, the next user function is tried.

Keep in mind that if polkit.Result.AUTH_SELF_KEEP or polkit.Result.AUTH_ADMIN_KEEP is returned, authorization checks for the same action identifier and subject will succeed (that is, return polkit.Result.YES) for the next brief period (e.g. five minutes) even if the variables passed along with the check are different. Therefore, if the result of an authorization rule depend on such variables, it should not use the "*_KEEP" constants (if similar functionality is required, the authorization rule can easily implement temporary authorizations using the Date[9] type for timestamps).

The addAdminRule() method is used for adding a function that may be called whenever administrator authentication is required. The function is used to specify what identities may be used for administrator authentication for the authorization check identified by action and subject. Functions added are called in the order they have been added until one of the functions returns a value. Each function should return an array of strings where each string is of the form "unix-group:<group>", "unix-netgroup:<netgroup>" or "unix-user:<user>". If the function returns null, undefined or does not return a value at all, the next function is tried.

There is no guarantee that a function registered with addRule() or addAdminRule() is ever called - for example an early rules file could register a function that always returns a value, hence ensuring that functions added later are never called.

If user-provided code takes a long time to execute, an exception will be thrown which normally results in the function being terminated (the current limit is 15 seconds). This is used to catch runaway scripts.

The spawn() method spawns an external helper identified by the argument vector argv and waits for it to terminate. If an error occurs or the helper doesn't exit normally with exit code 0, an exception is thrown. If the helper does not exit within 10 seconds, it is killed. Otherwise, the program's standard output is returned as a string. The spawn() method should be used sparingly as helpers may take a very long or indeterminate amount of time to complete and no other authorization check can be handled while the helper is running. Note that the spawned programs will run as the unprivileged polkitd system user.

The log() method writes the given message to the system logger prefixed with the JavaScript filename and line number. Log entries are emitted using the LOG_AUTHPRIV flag meaning that the log entries usually ends up in the file /var/log/secure. The log() method is usually only used when debugging rules. The Action and Subject types has suitable toString() methods defined for easy logging, for example,

```
polkit.addRule(function(action, subject) {

    if (action.id == "org.freedesktop.policykit.exec") {

        polkit.log("action=" + action);

        polkit.log("subject=" + subject);

    }
});
```

will produce the following when the user runs 'pkexec -u bateman bash -i' from a shell:

```
May 24 14:28:50 thinkpad polkitd[32217]: /etc/polkit-1/rules.d/10-test.rules:3: action=[Action id='org.freedesktop.policykit.exec' command_line='/usr/bin/bash -i' program='/usr/bin/bash' user='bateman' user.gecos='Patrick Bateman' user.display='Patrick Bateman (bateman)']
May 24 14:28:50 thinkpad polkitd[32217]: /etc/polkit-1/rules.d/10-test.rules:4: subject=[Subject pid=1352 user='davidz' groups=davidz,wheel, seat='seat0' session='1' local=true active=true]
```

### The Action type
The action parameter passed to user functions is an object with information about the action being checked. It is of type Action and has the following attribute:

string id

The action identifier, for example org.freedesktop.policykit.exec.

The following methods are available on the Action type:

string lookup(string key);

The lookup() method is used to lookup the polkit variables passed from the mechanism. For example, the pkexec(1) mechanism sets the variable program which can be obtained in JavaScript using the expression action.lookup("program"). If there is no value for the given key, then undefined is returned.

Consult the documentation for each mechanism for what variables are available for each action.

### The Subject type
The subject parameter passed to user functions is an object with information about the process being checked. It is of type Subject and has the following attributes

int pid

The process id.

string user

The user name.

string[] groups

Array of groups that user user belongs to.

string seat

The seat that the subject is associated with - blank if not on a local seat.

string session

The session that the subject is associated with.

boolean local

Set to true only if seat is local.

boolean active

Set to true only if the session is active.

The following methods are available on the Subject type:

boolean isInGroup(string groupName);

boolean isInNetGroup(string netGroupName);

The isInGroup() method can be used to check if the subject is in a given group and isInNetGroup() can be used to check if the subject is in a given netgroup.

### Authorization Rules Examples
Allow all users in the admin group to perform user administration without changing policy for other users:

```
polkit.addRule(function(action, subject) {

    if (action.id == "org.freedesktop.accounts.user-administration" &&

        subject.isInGroup("admin")) {

        return polkit.Result.YES;

    }
});
```

Define administrative users to be the users in the wheel group:

```
polkit.addAdminRule(function(action, subject) {

    return ["unix-group:wheel"];
});
```

Forbid users in group children to change hostname configuration (that is, any action with an identifier starting with org.freedesktop.hostname1.) and allow anyone else to do it after authenticating as themselves:

```
polkit.addRule(function(action, subject) {

    if (action.id.indexOf("org.freedesktop.hostname1.") == 0) {

        if (subject.isInGroup("children")) {

            return polkit.Result.NO;

        } else {

            return polkit.Result.AUTH_SELF_KEEP;

        }

    }
});
```

Run an external helper to determine if the current user may reboot the system:

```
polkit.addRule(function(action, subject) {

    if (action.id.indexOf("org.freedesktop.login1.reboot") == 0) {

        try {

            // user-may-reboot exits with success (exit code 0)

            // only if the passed username is authorized

            polkit.spawn(["/opt/company/bin/user-may-reboot",

                          subject.user]);

            return polkit.Result.YES;

        } catch (error) {

            // Nope, but do allow admin authentication

            return polkit.Result.AUTH_ADMIN;

        }

    }
});
```

The following example shows how the authorization decision can depend on variables passed by the pkexec(1) mechanism:

```
polkit.addRule(function(action, subject) {

    if (action.id == "org.freedesktop.policykit.exec" &&

        action.lookup("program") == "/usr/bin/cat") {

        return polkit.Result.AUTH_ADMIN;

    }
});
```

The following example shows another use of variables passed from the mechanism. In this case, the mechanism is UDisks[10] which defines a set of actions and variables[11] that is used to match on:

```
// Allow users in group 'engineers' to perform any operation on
// some drives without having to authenticate
//
polkit.addRule(function(action, subject) {

    if (action.id.indexOf("org.freedesktop.udisks2.") == 0 &&

        action.lookup("drive.vendor") == "SEAGATE" &&

        action.lookup("drive.model") == "ST3300657SS" &&

        subject.isInGroup("engineers")) {

            return polkit.Result.YES;

        }

    }
});
```

## AUTHOR
Written by David Zeuthen <davidz@redhat.com> with a lot of help from many others.

## BUGS
Please send bug reports to either the distribution or the polkit-devel mailing list, see the link http://lists.freedesktop.org/mailman/listinfo/polkit-devel on how to subscribe.

## SEE ALSO
polkitd(8), pkaction(1), pkcheck(1), pkexec(1), pkttyagent(1)

## NOTES
1.

/usr/share/gtk-doc/html/polkit-1/polkit-architecture.png

2.

GObjectIntrospection

https://live.gnome.org/GObjectIntrospection

3.

developer documentation

http://www.freedesktop.org/software/polkit/docs/latest/

4.

/usr/share/gtk-doc/html/polkit-1/polkit-authentication-agent-example.png

5.

/usr/share/gtk-doc/html/polkit-1/polkit-authentication-agent-example-wheel.png

6.

Freedesktop.org Icon Naming Specification

http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html

7.

JavaScript

http://en.wikipedia.org/wiki/JavaScript

8.

ECMA-262 edition 5

http://en.wikipedia.org/wiki/ECMAScript#ECMAScript.2C_5th_Edition

9.

Date

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date

10.

UDisks

http://udisks.freedesktop.org/docs/latest/udisks.8.html

11.

actions and variables

http://udisks.freedesktop.org/docs/latest/udisks-polkit-actions.html


polkitd

title: polkitd(8)

summary: The polkit system daemon

text:
# polkitd(8)

## NAME
polkitd - The polkit system daemon

## SYNOPSIS
polkitd

## DESCRIPTION
polkitd provides the org.freedesktop.PolicyKit1 D-Bus service on the system message bus. Users or administrators should never need to start this daemon as it will be automatically started by dbus-daemon(1) or systemd(1) whenever an application calls into the service.

polkitd must be started with superuser privileges but drops privileges early by switching to the unprivileged polkitd system user.

See the polkit(8) man page for more information.

## AUTHOR
Written by David Zeuthen <davidz@redhat.com> with a lot of help from many others.

## BUGS
Please send bug reports to either the distribution or the polkit-devel mailing list, see the link http://lists.freedesktop.org/mailman/listinfo/polkit-devel on how to subscribe.

## SEE ALSO
polkit(8), pkaction(1), pkcheck(1), pkexec(1), pkttyagent(1), dbus-daemon(1), systemd(1)


pkla-admin-identities

package: polkit-pkla-compat

title: pkla-admin-identities(8)

summary: List pklocalauthority\-configured polkit administrators

text:
# pkla-admin-identities(8)

## NAME
pkla-admin-identities - List pklocalauthority-configured polkit administrators

## SYNOPSIS
pkla-admin-identities [--help]

pkla-admin-identities [--config-path config-path]

## DESCRIPTION
pkla-admin-identities interprets configuration files described below to determine which users polkit(8) considers administrators, using a non-JavaScript configuration file format described below.

Note: Determining which users are considered administrators is driven by JavaScript rules as described in polkit(8). pkla-admin-identities is called by a JavaScript rule file named 49-polkit-pkla-compat.rules; other JavaScript rules with a higher priority may exist, so the pkla-admin-identities configuration may not necessarily govern the final decision by polkit(8).

The ordering of the JavaScript rule files and the ordering of pkla-admin-identities configuration files is not integrated and uses different rules; the pkla-admin-identities configuration evaluation is happens at a single point within the JavaScript rule evaluation order.

pkla-admin-identities is an internal helper program of pkla-polkit-compat. You shouldn't need to run it directly, except for debugging purposes.

Configuration is read from files with a .conf extension in the /etc/polkit-1/localauthority.conf.d directory. All files are read in lexicographical order (using the C locale), meaning that later files can override earlier ones. The file 50-localauthority.conf contains the settings provided by the OS vendor. Users and 3rd party packages can drop configuration files with a priority higher than 60 to change the defaults. The configuration file format is simple. Each configuration file is a key file (also commonly known as a ini file) with a single group called [Configuration]. Only a single key, AdminIdentities is read. The value of this key is a semi-colon separated list of identities that can be used when administrator authentication is required. Users are specified by prefixing the user name with unix-user:, groups of users are specified by prefixing with unix-group:, and netgroups of users are specified with unix-netgroup:. See the section called “EXAMPLE” for an example of a configuration file.

pkla-admin-identities outputs the resulting configuration of administrator identities, one identity per line, using the same format (including e.g. the unix-user: prefix). If no administrator identities are configured in the above-described configuration files, the output will be empty.

## OPTIONS
-h, --help

Write a summary of the available options to standard output and exit successfully.

-c, --config-path=config-path

Search for configuration files in config-path instead of the default /etc/polkit-1/localauthority.conf.d.

## EXIT STATUS
pkla-admin-identities exits with 0 on success (even if there are no administrator identities), and a non-zero status on error.

## FILES
/etc/polkit-1/localauthority.conf.d

Default directory containing configuration files.

## EXAMPLE
The following .conf file

```
[Configuration]
AdminIdentities=unix-group:staff

```

specifies that any user in the staff UNIX group can be used for authentication when administrator authentication is needed. This file would typically be installed in the /etc/polkit-1/localauthority.conf.d directory and given the name 60-desktop-policy.conf to ensure that it is evaluated after the 50-localauthority.conf file shipped with pkla-polkit-compat. If the local administrator wants to override this (suppose 60-desktop-policy.conf was shipped as part of the OS) he can simply create a file 99-my-admin-configuration.conf with the following content

```
[Configuration]
AdminIdentities=unix-user:lisa;unix-user:marge

```

to specify that only the users lisa and marge can authenticate when administrator authentication is needed.

## AUTHOR
Written by David Zeuthen <davidz@redhat.com> with a lot of help from many others. Adapted by Miloslav Trmač <mitr@redhat.com>.

## SEE ALSO
polkit(8)


pkla-check-authorization

title: pkla-check-authorization(8)

text:
# pkla-check-authorization(8)

## NAME
pkla-check-authorization - Evaluate pklocalauthority authorization configuration

## SYNOPSIS
pkla-check-authorization [--help]

pkla-check-authorization [--paths paths] {user-name} {is-local} {is-active} {action}

## DESCRIPTION
pkla-check-authorization interprets non-JavaScript configuration files described below to determine the response of polkit(8) to authorization queries.

Note: Authorization decision evaluation is driven by JavaScript rules as described in polkit(8). pkla-check-authorization is called by a JavaScript rule file named 49-polkit-pkla-compat.rules; other JavaScript rules with a higher priority may exist, so the pkla-check-authorization configuration may not necessarily govern the final polkit(8) authorization decision.

The ordering of the JavaScript rule files and the ordering of pkla-check-authorization configuration files is not integrated and uses different rules; the pkla-check-authorization configuration evaluation is happens at a single point within the JavaScript rule evaluation order.

pkla-check-authorization is an internal helper program of pkla-polkit-compat. You shouldn't need to run it directly, except for debugging purposes.

The arguments to pkla-check-authorization are, in order:

user-name

Name of the user account asking for authorization

is-local

Whether the attempted action is performed from a local login session, true or false.

is-active

Whether the attempted action is performed from a currently active session (e.g. currently active virtual console), true or false.

action

A string identifying the polkit(8) action.

If the configuration specifies an authorization decision, pkla-check-authorization outputs the decision and a terminating newline. If no decision is configured, the output is empty.

## OPTIONS
-h, --help

Write a summary of the available options to standard output and exit successfully.

-p, --paths=paths

Search for configuration files in semicolon-separated paths instead of the default /var/lib/polkit-1/localauthority;/etc/polkit-1/localauthority.

## EXIT STATUS
pkla-check-authorization exits with 0 on success (even if there is no decision configured), and a non-zero status on error.

## DIRECTORY STRUCTURE
Files with .pkla extension are read from all directories located inside the /etc/polkit-1/localauthority and /var/lib/polkit-1/localauthority directories (or as specified using the --paths option). By default, the following sub-directories are installed.

```
/etc/polkit-1/
`-- localauthority

    |-- 10-vendor.d

    |-- 20-org.d

    |-- 30-site.d

    |-- 50-local.d

    `-- 90-mandatory.d

```

and

```
/var/lib/polkit-1/
`-- localauthority

    |-- 10-vendor.d

    |-- 20-org.d

    |-- 30-site.d

    |-- 50-local.d

    `-- 90-mandatory.d

```

The /etc/polkit-1/localauthority hierarchy is intended for local configuration and the /var/lib/polkit-1/localauthority is intended for 3rd party packages.

Each .pkla file contains one or more authorization entries. If the underlying filesystem supports file monitoring, the Local Authority will reload information whenever .pkla files are added, removed or changed.

Each directory is intended for a specific audience

10-vendor.d

Intended for use by the OS vendor.

20-org.d

Intended for the organization deploying the OS.

30-site.d

Intended for the site deploying the system.

50-local.d

Intended for local usage.

90-mandatory.d

Intended for the organization deploying the OS.

and new directories can be added/removed as needed.

As to regards to the content, each .pkla file is a standard key file and contains key/value pairs in one or more groups with each group representing an authorization entry. A .pkla file MUST be named by using a scheme to ensure that the name is unique, e.g. reverse DNS notation or similar. For example, if the organization is “Acme Corp” needs to modify policy for the product “Frobnicator”, a name like com.acme.frobnicator.pkla would be suitable.

## AUTHORIZATION ENTRY
Each group in a .pkla file must have a name that is unique within the file it belongs to. The following keys are recognized:

Identity

A semi-colon separated list of entries to match identities. Each entry should start with unix-user: or unix-group: to specify whether to match on a UNIX user name or a UNIX group name, and continue with a glob matching the group or user name. Netgroups are supported with the unix-netgroup: prefix, but cannot support glob syntax. Finally, an entry "default" (with no prefix) can be used to specify the default match.

Action

A semi-colon separated list of globs to match action identifiers.

ResultActive

The result to return for subjects in an active local session that matches one or more of the given identities. Allowed values are similar to what can be used in the defaults section of .policy files used to define actions, e.g. yes, no, auth_self, auth_self_keep, auth_admin and auth_admin_keep.

ResultInactive

Like ResultActive but instead applies to subjects in inactive local sessions.

ResultAny

Like ResultActive but instead applies to any subject.

All keys specified above are required except that only at least one of ResultAny, ResultInactive and ResultActive must be present.

## EVALUATION ORDER
The authorization entries discussed above are consulted using the following algorithm.

The authorization entries from all .pkla files are ordered using the following rules. First all the basename of all sub-directories (e.g. 30-site.d) from both the /etc/polkit-1/localauthority and /var/lib/polkit-1/localauthority directories are enumerated and sorted (using the C locale). If a name exists in both /etc and /var, the one in /etc takes precedence. Then all .pkla files are read in order from this list of sub-directories. For each .pkla file, authorizations from each file are appended in order resulting in an ordered list of authorization entries.

For example, given the following files

```
/var/lib/polkit-1
└── localauthority

    ├── 10-vendor.d

    │   └── 10-desktop-policy.pkla

    ├── 20-org.d

    ├── 30-site.d

    ├── 50-local.d

    ├── 55-org.my.company.d

    │   └── 10-org.my.company.product.pkla

    └── 90-mandatory.d
/etc/polkit-1
└── localauthority

    ├── 10-vendor.d

    │   └── 01-some-changes-from-a-subvendor.pkla

    ├── 20-org.d

    ├── 30-site.d

    ├── 50-local.d

    ├── 55-org.my.company.d

    │   └── 10-org.my.company.product.pkla

    └── 90-mandatory.d

```

the evaluation order of the .pkla files is:

1. 10-desktop-policy.pkla

2. 01-some-changes-from-a-subvendor.pkla

3. 10-org.my.company.product.pkla (the /var one)

4. 10-org.my.company.product.pkla (the /etc one)

When the list of authorization entries has been calculated, the authorization check can be made. First, the user of the Subject is determined and the groups that the user belongs are looked up.

Then, authorization entries that include the "default" field value in the Identity field are consulted in order. If the authorization entry matches the data from the authorization check, then the authorization result from RequireAny, RequireInactive or RequireActive is used.

Next, for each group identity, all authorization entries that contain a matching group entry are again consulted in the same manner.

Finally, the authorization entries are consulted using the user identity in the same manner.

Note that processing continues even after a match. This allows for so called “negative authorizations”, see the section called “EXAMPLE” for further discussion.

## EXAMPLE
The following .pkla file grants authorization to all users in the staff group for actions matching the glob com.example.awesomeproduct.* provided they are in an active session on the local console:

```
[Normal Staff Permissions]
Identity=unix-group:staff
Action=com.example.awesomeproduct.*
ResultAny=no
ResultInactive=no
ResultActive=yes

```

If the users homer and grimes are member of the staff group but policy requires that an administrator needs to authenticate every time authorization for any action matching com.example.awesomeproduct.* is required, one would add

```
[Exclude Some Problematic Users]
Identity=unix-user:homer;unix-user:grimes
Action=com.example.awesomeproduct.*
ResultAny=no
ResultInactive=no
ResultActive=auth_admin

```

and make sure this authorization entry is after the first one.

The following entry modifies the default authorization decision (it is overridden by any entry that matches using unix-user: or unix-group:, but overrides any defaults set by the application author in an .action file):

```
[Disable Access by Default]
Identity=default
Action=com.example.awesomeproduct.*
ResultAny=no
ResultInactive=no
ResultActive=no

```

## FILES
/etc/polkit-1/localauthority, /var/lib/polkit-1/localauthority

Default directories containing decision configuration files.

## AUTHOR
Written by David Zeuthen <davidz@redhat.com> with a lot of help from many others. Adapted by Miloslav Trmač <mitr@redhat.com>.

## SEE ALSO
polkit(8)


pklocalauthority

title: pklocalauthority(8)

summary: polkit Local Authority Compatibility

text:
# pklocalauthority(8)

## NAME
pklocalauthority - polkit Local Authority Compatibility

## DESCRIPTION
The polkit Local Authority no longer exists. Existing configuration files are honored; see pkla-admin-identities(8) and pkla-check-authorization(8) for description of the configuration format.

Unlike the original Local Authority implementation, ReturnValue keys are ignored because polkit(8) no longer supports the functionality.

## SEE ALSO
pkla-admin-identities(8), pkla-check-authorization(8), polkit(8)

## AUTHOR
Miloslav Trmač <mitr@redhat.com>

Author


title: popa3d(8)

summary: Post Office Protocol (POP3) server

text:
# popa3d(8)

## NAME
popa3d - Post Office Protocol (POP3) server

## SYNOPSIS
popa3d [-D] [-V]

## DESCRIPTION
popa3d is a Post Office Protocol version 3 (POP3) server.

A POP3 server operates on local mailboxes on behalf of its remote users. Users can connect at any time to check their mailbox and fetch the mail that has accumulated. The advantage of this "pull" approach is that any user with a simple POP3-capable mail reader program can receive mail, eschewing the need for a full-fledged Mail Transfer Agent (MTA) and a permanent network connection.

Note that POP3 can only be used to retrieve mail, not to send it. To send mail, the SMTP protocol is commonly used.

For access to a mailbox through POP3, the username must be in the password database. Additionally, popa3d does not permit null passwords and will refuse to serve mail for root (UID 0) users.

## OPTIONS
-D

Standalone server mode. In this mode, popa3d will become a daemon, accepting connections on the pop3 port (110/tcp) and forking child processes to handle them. This has lower overhead than starting popa3d from an inetd equivalent (which popa3d assumes by default) and is thus useful on busy servers to reduce load. In this mode popa3d also does quite a few checks to significantly reduce the impact of connection flood attacks.

-V

Print version information and exit.

## COMMANDS
A normal POP3 session progresses through three states: AUTHORIZATION, TRANSACTION, and UPDATE.

After the TCP connection opens, the client must authenticate itself to the server during the AUTHORIZATION state. The following commands are supported in the AUTHORIZATION state (all command names are case-insensitive).

USER name

Authenticate as user name.

PASS string

Authenticate using password string.

QUIT

Quit; do not enter UPDATE state.

When authorization is successful, the server enters the TRANSACTION state. The client can now list and retrieve messages or mark messages for deletion. The following commands are supported in the TRANSACTION state.

DELE msg

Mark message for deletion.

LAST

Show highest message number accessed (obsolete).

LIST [msg]

List message number and size.

NOOP

Do nothing.

QUIT

Quit; enter UPDATE state.

RETR msg

Retrieve message.

RSET

Clear deletion marks.

STAT

Return total number of messages and total size.

TOP msg n

Show top n lines of message body.

UIDL [msg]

List message number and digest.

When the client issues the QUIT command in the TRANSACTION state, the server enters the UPDATE state. All messages that were marked for deletion are now removed. The server then closes the connection.

## BUGS
POP3 transmits passwords in plaintext and thus, if you care about the security of your individual user accounts, should only be used either in trusted networks or tunneled over encrypted channels.

There exist extensions to the protocol that are supposed to fix this problem. popa3d does not support them yet, partly because this isn't going to fully fix the problem. In fact, APOP and the weaker defined SASL mechanisms such as CRAM-MD5 may potentially be even less secure than transmission of plaintext passwords because of the requirement that plaintext equivalents be stored on the server.

## AUTHORS
Solar Designer <solar at openwall.com>

This manual page is based heavily on the one Camiel Dobbelaar wrote for OpenBSD.

## SEE ALSO
Official Internet Protocol Standard STD 53, also known as RFC 1939.

http://www.openwall.com/popa3d/


anvil

package: postfix

title: anvil(8)

text:
# anvil(8)

## NAME
anvil - Postfix session count and request rate control

## SYNOPSIS

```
anvil [generic Postfix daemon options]
```

## DESCRIPTION

The Postfix anvil(8) server maintains statistics about client connection counts or client request rates. This information can be used to defend against clients that hammer a server with either too many simultaneous sessions, or with too many successive requests within a configurable time interval. This server is designed to run under control by the Postfix master(8) server.

In the following text, ident specifies a (service, client) combination. The exact syntax of that information is application-dependent; the anvil(8) server does not care.

## CONNECTION COUNT/RATE CONTROL

```

```

To register a new connection send the following request to the anvil(8) server:

```
    request=connect

    ident=string
```

The anvil(8) server answers with the number of simultaneous connections and the number of connections per unit time for the (service, client) combination specified with ident:

```
    status=0

    count=number

    rate=number
```

To register a disconnect event send the following request to the anvil(8) server:

```
    request=disconnect

    ident=string
```

The anvil(8) server replies with:

```
    status=0
```

## MESSAGE RATE CONTROL

```

```

To register a message delivery request send the following request to the anvil(8) server:

```
    request=message

    ident=string
```

The anvil(8) server answers with the number of message delivery requests per unit time for the (service, client) combination specified with ident:

```
    status=0

    rate=number
```

## RECIPIENT RATE CONTROL

```

```

To register a recipient request send the following request to the anvil(8) server:

```
    request=recipient

    ident=string
```

The anvil(8) server answers with the number of recipient addresses per unit time for the (service, client) combination specified with ident:

```
    status=0

    rate=number
```

## TLS SESSION NEGOTIATION RATE CONTROL

```

```

The features described in this section are available with Postfix 2.3 and later.

To register a request for a new (i.e. not cached) TLS session send the following request to the anvil(8) server:

```
    request=newtls

    ident=string
```

The anvil(8) server answers with the number of new TLS session requests per unit time for the (service, client) combination specified with ident:

```
    status=0

    rate=number
```

To retrieve new TLS session request rate information without updating the counter information, send:

```
    request=newtls_report

    ident=string
```

The anvil(8) server answers with the number of new TLS session requests per unit time for the (service, client) combination specified with ident:

```
    status=0

    rate=number
```

## AUTH RATE CONTROL

```

```

To register an AUTH request send the following request to the anvil(8) server:

```
    request=auth

    ident=string
```

The anvil(8) server answers with the number of auth requests per unit time for the (service, client) combination specified with ident:

```
    status=0

    rate=number
```

## SECURITY

```

```

The anvil(8) server does not talk to the network or to local users, and can run chrooted at fixed low privilege.

The anvil(8) server maintains an in-memory table with information about recent clients requests. No persistent state is kept because standard system library routines are not sufficiently robust for update-intensive applications.

Although the in-memory state is kept only temporarily, this may require a lot of memory on systems that handle connections from many remote clients. To reduce memory usage, reduce the time unit over which state is kept.

## DIAGNOSTICS

Problems and transactions are logged to syslogd(8) or postlogd(8).

Upon exit, and every anvil_status_update_time seconds, the server logs the maximal count and rate values measured, together with (service, client) information and the time of day associated with those events. In order to avoid unnecessary overhead, no measurements are done for activity that isn't concurrency limited or rate limited.

## BUGS

Systems behind network address translating routers or proxies appear to have the same client address and can run into connection count and/or rate limits falsely.

In this preliminary implementation, a count (or rate) limited server process can have only one remote client at a time. If a server process reports multiple simultaneous clients, state is kept only for the last reported client.

The anvil(8) server automatically discards client request information after it expires. To prevent the anvil(8) server from discarding client request rate information too early or too late, a rate limited service should always register connect/disconnect events even when it does not explicitly limit them.

## CONFIGURATION PARAMETERS

```

```

On low-traffic mail systems, changes to main.cf are picked up automatically as anvil(8) processes run for only a limited amount of time. On other mail systems, use the command "postfix reload" to speed up a change.

The text below provides only a parameter summary. See postconf(5) for more details including examples.

anvil_rate_time_unit (60s)

The time unit over which client connection rates and other rates are calculated.

anvil_status_update_time (600s)

How frequently the anvil(8) connection and rate limiting server logs peak usage information.

config_directory (see 'postconf -d' output)

The default location of the Postfix main.cf and master.cf configuration files.

daemon_timeout (18000s)

How much time a Postfix daemon process may take to handle a request before it is terminated by a built-in watchdog timer.

ipc_timeout (3600s)

The time limit for sending or receiving information over an internal communication channel.

max_idle (100s)

The maximum amount of time that an idle Postfix daemon process waits for an incoming connection before terminating voluntarily.

max_use (100)

The maximal number of incoming connections that a Postfix daemon process will service before terminating voluntarily.

process_id (read-only)

The process ID of a Postfix command or daemon process.

process_name (read-only)

The process name of a Postfix command or daemon process.

syslog_facility (mail)

The syslog facility of Postfix logging.

syslog_name (see 'postconf -d' output)

A prefix that is prepended to the process name in syslog records, so that, for example, "smtpd" becomes "prefix/smtpd".

Available in Postfix 3.3 and later:

service_name (read-only)

The master.cf service name of a Postfix daemon process.

## SEE ALSO

```
smtpd(8), Postfix SMTP server
postconf(5), configuration parameters
master(5), generic daemon options
```

## README FILES

```

```

Use "postconf readme_directory" or "postconf html_directory" to locate this information.

```
TUNING_README, performance tuning
```

## LICENSE

```

```

The Secure Mailer license must be distributed with this software.

## HISTORY

The anvil service is available in Postfix 2.2 and later.

## AUTHOR(S)

```
Wietse Venema
IBM T.J. Watson Research
P.O. Box 704
Yorktown Heights, NY 10598, USA
Wietse Venema
Google, Inc.
111 8th Avenue
New York, NY 10011, USA
```


bounce

title: bounce(8)

text:
# bounce(8)

## NAME
bounce - Postfix delivery status reports

## SYNOPSIS

```
bounce [generic Postfix daemon options]
```

## DESCRIPTION

The bounce(8) daemon maintains per-message log files with delivery status information. Each log file is named after the queue file that it corresponds to, and is kept in a queue subdirectory named after the service name in the master.cf file (either bounce, defer or trace). This program expects to be run from the master(8) process manager.

The bounce(8) daemon processes two types of service requests:

- Append a recipient (non-)delivery status record to a per-message log file.

- Enqueue a delivery status notification message, with a copy of a per-message log file and of the corresponding message. When the delivery status notification message is enqueued successfully, the per-message log file is deleted.

The software does a best notification effort. A non-delivery notification is sent even when the log file or the original message cannot be read.

Optionally, a bounce (defer, trace) client can request that the per-message log file be deleted when the requested operation fails. This is used by clients that cannot retry transactions by themselves, and that depend on retry logic in their own client.

## STANDARDS

```
RFC 822 (ARPA Internet Text Messages)
RFC 2045 (Format of Internet Message Bodies)
RFC 2822 (Internet Message Format)
RFC 3462 (Delivery Status Notifications)
RFC 3464 (Delivery Status Notifications)
RFC 3834 (Auto-Submitted: message header)
RFC 5322 (Internet Message Format)
RFC 6531 (Internationalized SMTP)
RFC 6532 (Internationalized Message Format)
RFC 6533 (Internationalized Delivery Status Notifications)
```

## DIAGNOSTICS

Problems and transactions are logged to syslogd(8) or postlogd(8).

## CONFIGURATION PARAMETERS

```

```

Changes to main.cf are picked up automatically, as bounce(8) processes run for only a limited amount of time. Use the command "postfix reload" to speed up a change.

The text below provides only a parameter summary. See postconf(5) for more details including examples.

2bounce_notice_recipient (postmaster)

The recipient of undeliverable mail that cannot be returned to the sender.

backwards_bounce_logfile_compatibility (yes)

Produce additional bounce(8) logfile records that can be read by Postfix versions before 2.0.

bounce_notice_recipient (postmaster)

The recipient of postmaster notifications with the message headers of mail that Postfix did not deliver and of SMTP conversation transcripts of mail that Postfix did not receive.

bounce_size_limit (50000)

The maximal amount of original message text that is sent in a non-delivery notification.

bounce_template_file (empty)

Pathname of a configuration file with bounce message templates.

config_directory (see 'postconf -d' output)

The default location of the Postfix main.cf and master.cf configuration files.

daemon_timeout (18000s)

How much time a Postfix daemon process may take to handle a request before it is terminated by a built-in watchdog timer.

delay_notice_recipient (postmaster)

The recipient of postmaster notifications with the message headers of mail that cannot be delivered within $delay_warning_time time units.

deliver_lock_attempts (20)

The maximal number of attempts to acquire an exclusive lock on a mailbox file or bounce(8) logfile.

deliver_lock_delay (1s)

The time between attempts to acquire an exclusive lock on a mailbox file or bounce(8) logfile.

ipc_timeout (3600s)

The time limit for sending or receiving information over an internal communication channel.

internal_mail_filter_classes (empty)

What categories of Postfix-generated mail are subject to before-queue content inspection by non_smtpd_milters, header_checks and body_checks.

mail_name (Postfix)

The mail system name that is displayed in Received: headers, in the SMTP greeting banner, and in bounced mail.

max_idle (100s)

The maximum amount of time that an idle Postfix daemon process waits for an incoming connection before terminating voluntarily.

max_use (100)

The maximal number of incoming connections that a Postfix daemon process will service before terminating voluntarily.

notify_classes (resource, software)

The list of error classes that are reported to the postmaster.

process_id (read-only)

The process ID of a Postfix command or daemon process.

process_name (read-only)

The process name of a Postfix command or daemon process.

queue_directory (see 'postconf -d' output)

The location of the Postfix top-level queue directory.

syslog_facility (mail)

The syslog facility of Postfix logging.

syslog_name (see 'postconf -d' output)

A prefix that is prepended to the process name in syslog records, so that, for example, "smtpd" becomes "prefix/smtpd".

Available in Postfix 3.0 and later:

smtputf8_autodetect_classes (sendmail, verify)

Detect that a message requires SMTPUTF8 support for the specified mail origin classes.

Available in Postfix 3.3 and later:

service_name (read-only)

The master.cf service name of a Postfix daemon process.

Available in Postfix 3.6 and later:

enable_threaded_bounces (no)

Enable non-delivery, success, and delay notifications that link to the original message by including a References: and In-Reply-To: header with the original Message-ID value.

## FILES

```
/var/spool/postfix/bounce/* non-delivery records
/var/spool/postfix/defer/* non-delivery records
/var/spool/postfix/trace/* delivery status records
```

## SEE ALSO

```
bounce(5), bounce message template format
qmgr(8), queue manager
postconf(5), configuration parameters
master(5), generic daemon options
master(8), process manager
postlogd(8), Postfix logging
syslogd(8), system logging
```

## LICENSE

```

```

The Secure Mailer license must be distributed with this software.

## AUTHOR(S)

```
Wietse Venema
IBM T.J. Watson Research
P.O. Box 704
Yorktown Heights, NY 10598, USA
Wietse Venema
Google, Inc.
111 8th Avenue
New York, NY 10011, USA
```


cleanup

title: cleanup(8)

text:
# cleanup(8)

## NAME
cleanup - canonicalize and enqueue Postfix message

## SYNOPSIS

```
cleanup [generic Postfix daemon options]
```

## DESCRIPTION

The cleanup(8) daemon processes inbound mail, inserts it into the incoming mail queue, and informs the queue manager of its arrival.

The cleanup(8) daemon performs the following transformations:

- Insert missing message headers: (Resent-) From:, To:, Message-Id:, and Date:.

This is enabled with the local_header_rewrite_clients and always_add_missing_headers parameter settings.

- Transform envelope and header addresses to the standard user@fully-qualified-domain form that is expected by other Postfix programs. This task depends on the trivial-rewrite(8) daemon.

The header transformation is enabled with the local_header_rewrite_clients parameter setting.

- Eliminate duplicate envelope recipient addresses.

This is enabled with the duplicate_filter_limit parameter setting.

- Remove message headers: Bcc, Content-Length, Resent-Bcc, Return-Path.

This is enabled with the message_drop_headers parameter setting.

- Optionally, rewrite all envelope and header addresses according to the mappings specified in the canonical(5) lookup tables.

The header transformation is enabled with the local_header_rewrite_clients parameter setting.

- Optionally, masquerade envelope sender addresses and message header addresses (i.e. strip host or domain information below all domains listed in the masquerade_domains parameter, except for user names listed in masquerade_exceptions). By default, address masquerading does not affect envelope recipients.

The header transformation is enabled with the local_header_rewrite_clients parameter setting.

- Optionally, expand envelope recipients according to information found in the virtual_alias_maps lookup tables.

The cleanup(8) daemon performs sanity checks on the content of each message. When it finds a problem, by default it returns a diagnostic status to the cleanup service client, and leaves it up to the client to deal with the problem. Alternatively, the client can request the cleanup(8) daemon to bounce the message back to the sender in case of trouble.

## STANDARDS

```
RFC 822 (ARPA Internet Text Messages)
RFC 2045 (MIME: Format of Internet Message Bodies)
RFC 2046 (MIME: Media Types)
RFC 2822 (Internet Message Format)
RFC 3463 (Enhanced Status Codes)
RFC 3464 (Delivery status notifications)
RFC 5322 (Internet Message Format)
```

## DIAGNOSTICS

Problems and transactions are logged to syslogd(8) or postlogd(8).

## BUGS

Table-driven rewriting rules make it hard to express if then else and other logical relationships.

## CONFIGURATION PARAMETERS

```

```

Changes to main.cf are picked up automatically, as cleanup(8) processes run for only a limited amount of time. Use the command "postfix reload" to speed up a change.

The text below provides only a parameter summary. See postconf(5) for more details including examples.

## COMPATIBILITY CONTROLS

```

```

undisclosed_recipients_header (see 'postconf -d' output)

Message header that the Postfix cleanup(8) server inserts when a message contains no To: or Cc: message header.

Available in Postfix version 2.1 only:

enable_errors_to (no)

Report mail delivery errors to the address specified with the non-standard Errors-To: message header, instead of the envelope sender address (this feature is removed with Postfix version 2.2, is turned off by default with Postfix version 2.1, and is always turned on with older Postfix versions).

Available in Postfix version 2.6 and later:

always_add_missing_headers (no)

Always add (Resent-) From:, To:, Date: or Message-ID: headers when not present.

Available in Postfix version 2.9 and later:

enable_long_queue_ids (no)

Enable long, non-repeating, queue IDs (queue file names).

Available in Postfix version 3.0 and later:

message_drop_headers (bcc, content-length, resent-bcc, return-path)

Names of message headers that the cleanup(8) daemon will remove after applying header_checks(5) and before invoking Milter applications.

## BUILT-IN CONTENT FILTERING CONTROLS

```

```

Postfix built-in content filtering is meant to stop a flood of worms or viruses. It is not a general content filter.

body_checks (empty)

Optional lookup tables for content inspection as specified in the body_checks(5) manual page.

header_checks (empty)

Optional lookup tables for content inspection of primary non-MIME message headers, as specified in the header_checks(5) manual page.

Available in Postfix version 2.0 and later:

body_checks_size_limit (51200)

How much text in a message body segment (or attachment, if you prefer to use that term) is subjected to body_checks inspection.

mime_header_checks ($header_checks)

Optional lookup tables for content inspection of MIME related message headers, as described in the header_checks(5) manual page.

nested_header_checks ($header_checks)

Optional lookup tables for content inspection of non-MIME message headers in attached messages, as described in the header_checks(5) manual page.

Available in Postfix version 2.3 and later:

message_reject_characters (empty)

The set of characters that Postfix will reject in message content.

message_strip_characters (empty)

The set of characters that Postfix will remove from message content.

## BEFORE QUEUE MILTER CONTROLS

```

```

As of version 2.3, Postfix supports the Sendmail version 8 Milter (mail filter) protocol. When mail is not received via the smtpd(8) server, the cleanup(8) server will simulate SMTP events to the extent that this is possible. For details see the MILTER_README document.

non_smtpd_milters (empty)

A list of Milter (mail filter) applications for new mail that does not arrive via the Postfix smtpd(8) server.

milter_protocol (6)

The mail filter protocol version and optional protocol extensions for communication with a Milter application; prior to Postfix 2.6 the default protocol is 2.

milter_default_action (tempfail)

The default action when a Milter (mail filter) response is unavailable (for example, bad Postfix configuration or Milter failure).

milter_macro_daemon_name ($myhostname)

The {daemon_name} macro value for Milter (mail filter) applications.

milter_macro_v ($mail_name $mail_version)

The {v} macro value for Milter (mail filter) applications.

milter_connect_timeout (30s)

The time limit for connecting to a Milter (mail filter) application, and for negotiating protocol options.

milter_command_timeout (30s)

The time limit for sending an SMTP command to a Milter (mail filter) application, and for receiving the response.

milter_content_timeout (300s)

The time limit for sending message content to a Milter (mail filter) application, and for receiving the response.

milter_connect_macros (see 'postconf -d' output)

The macros that are sent to Milter (mail filter) applications after completion of an SMTP connection.

milter_helo_macros (see 'postconf -d' output)

The macros that are sent to Milter (mail filter) applications after the SMTP HELO or EHLO command.

milter_mail_macros (see 'postconf -d' output)

The macros that are sent to Milter (mail filter) applications after the SMTP MAIL FROM command.

milter_rcpt_macros (see 'postconf -d' output)

The macros that are sent to Milter (mail filter) applications after the SMTP RCPT TO command.

milter_data_macros (see 'postconf -d' output)

The macros that are sent to version 4 or higher Milter (mail filter) applications after the SMTP DATA command.

milter_unknown_command_macros (see 'postconf -d' output)

The macros that are sent to version 3 or higher Milter (mail filter) applications after an unknown SMTP command.

milter_end_of_data_macros (see 'postconf -d' output)

The macros that are sent to Milter (mail filter) applications after the message end-of-data.

Available in Postfix version 2.5 and later:

milter_end_of_header_macros (see 'postconf -d' output)

The macros that are sent to Milter (mail filter) applications after the end of the message header.

Available in Postfix version 2.7 and later:

milter_header_checks (empty)

Optional lookup tables for content inspection of message headers that are produced by Milter applications.

Available in Postfix version 3.1 and later:

milter_macro_defaults (empty)

Optional list of name=value pairs that specify default values for arbitrary macros that Postfix may send to Milter applications.

## MIME PROCESSING CONTROLS

```

```

Available in Postfix version 2.0 and later:

disable_mime_input_processing (no)

Turn off MIME processing while receiving mail.

mime_boundary_length_limit (2048)

The maximal length of MIME multipart boundary strings.

mime_nesting_limit (100)

The maximal recursion level that the MIME processor will handle.

strict_8bitmime (no)

Enable both strict_7bit_headers and strict_8bitmime_body.

strict_7bit_headers (no)

Reject mail with 8-bit text in message headers.

strict_8bitmime_body (no)

Reject 8-bit message body text without 8-bit MIME content encoding information.

strict_mime_encoding_domain (no)

Reject mail with invalid Content-Transfer-Encoding: information for the message/* or multipart/* MIME content types.

Available in Postfix version 2.5 and later:

detect_8bit_encoding_header (yes)

Automatically detect 8BITMIME body content by looking at Content-Transfer-Encoding: message headers; historically, this behavior was hard-coded to be "always on".

## AUTOMATIC BCC RECIPIENT CONTROLS

```

```

Postfix can automatically add BCC (blind carbon copy) when mail enters the mail system:

always_bcc (empty)

Optional address that receives a "blind carbon copy" of each message that is received by the Postfix mail system.

Available in Postfix version 2.1 and later:

sender_bcc_maps (empty)

Optional BCC (blind carbon-copy) address lookup tables, indexed by sender address.

recipient_bcc_maps (empty)

Optional BCC (blind carbon-copy) address lookup tables, indexed by recipient address.

## ADDRESS TRANSFORMATION CONTROLS

```

```

Address rewriting is delegated to the trivial-rewrite(8) daemon. The cleanup(8) server implements table driven address mapping.

empty_address_recipient (MAILER-DAEMON)

The recipient of mail addressed to the null address.

canonical_maps (empty)

Optional address mapping lookup tables for message headers and envelopes.

recipient_canonical_maps (empty)

Optional address mapping lookup tables for envelope and header recipient addresses.

sender_canonical_maps (empty)

Optional address mapping lookup tables for envelope and header sender addresses.

masquerade_classes (envelope_sender, header_sender, header_recipient)

What addresses are subject to address masquerading.

masquerade_domains (empty)

Optional list of domains whose subdomain structure will be stripped off in email addresses.

masquerade_exceptions (empty)

Optional list of user names that are not subjected to address masquerading, even when their addresses match $masquerade_domains.

propagate_unmatched_extensions (canonical, virtual)

What address lookup tables copy an address extension from the lookup key to the lookup result.

Available before Postfix version 2.0:

virtual_maps (empty)

Optional lookup tables with a) names of domains for which all addresses are aliased to addresses in other local or remote domains, and b) addresses that are aliased to addresses in other local or remote domains.

Available in Postfix version 2.0 and later:

virtual_alias_maps ($virtual_maps)

Optional lookup tables that alias specific mail addresses or domains to other local or remote address.

Available in Postfix version 2.2 and later:

canonical_classes (envelope_sender, envelope_recipient, header_sender, header_recipient)

What addresses are subject to canonical_maps address mapping.

recipient_canonical_classes (envelope_recipient, header_recipient)

What addresses are subject to recipient_canonical_maps address mapping.

sender_canonical_classes (envelope_sender, header_sender)

What addresses are subject to sender_canonical_maps address mapping.

remote_header_rewrite_domain (empty)

Don't rewrite message headers from remote clients at all when this parameter is empty; otherwise, rewrite message headers and append the specified domain name to incomplete addresses.

## RESOURCE AND RATE CONTROLS

```

```

duplicate_filter_limit (1000)

The maximal number of addresses remembered by the address duplicate filter for aliases(5) or virtual(5) alias expansion, or for showq(8) queue displays.

header_size_limit (102400)

The maximal amount of memory in bytes for storing a message header.

hopcount_limit (50)

The maximal number of Received: message headers that is allowed in the primary message headers.

in_flow_delay (1s)

Time to pause before accepting a new message, when the message arrival rate exceeds the message delivery rate.

message_size_limit (10240000)

The maximal size in bytes of a message, including envelope information.

Available in Postfix version 2.0 and later:

header_address_token_limit (10240)

The maximal number of address tokens are allowed in an address message header.

mime_boundary_length_limit (2048)

The maximal length of MIME multipart boundary strings.

mime_nesting_limit (100)

The maximal recursion level that the MIME processor will handle.

queue_file_attribute_count_limit (100)

The maximal number of (name=value) attributes that may be stored in a Postfix queue file.

Available in Postfix version 2.1 and later:

virtual_alias_expansion_limit (1000)

The maximal number of addresses that virtual alias expansion produces from each original recipient.

virtual_alias_recursion_limit (1000)

The maximal nesting depth of virtual alias expansion.

Available in Postfix version 3.0 and later:

virtual_alias_address_length_limit (1000)

The maximal length of an email address after virtual alias expansion.

## SMTPUTF8 CONTROLS

```

```

Preliminary SMTPUTF8 support is introduced with Postfix 3.0.

smtputf8_enable (yes)

Enable preliminary SMTPUTF8 support for the protocols described in RFC 6531..6533.

smtputf8_autodetect_classes (sendmail, verify)

Detect that a message requires SMTPUTF8 support for the specified mail origin classes.

Available in Postfix version 3.2 and later:

enable_idna2003_compatibility (no)

Enable 'transitional' compatibility between IDNA2003 and IDNA2008, when converting UTF-8 domain names to/from the ASCII form that is used for DNS lookups.

## MISCELLANEOUS CONTROLS

```

```

config_directory (see 'postconf -d' output)

The default location of the Postfix main.cf and master.cf configuration files.

daemon_timeout (18000s)

How much time a Postfix daemon process may take to handle a request before it is terminated by a built-in watchdog timer.

delay_logging_resolution_limit (2)

The maximal number of digits after the decimal point when logging sub-second delay values.

delay_warning_time (0h)

The time after which the sender receives a copy of the message headers of mail that is still queued.

ipc_timeout (3600s)

The time limit for sending or receiving information over an internal communication channel.

max_idle (100s)

The maximum amount of time that an idle Postfix daemon process waits for an incoming connection before terminating voluntarily.

max_use (100)

The maximal number of incoming connections that a Postfix daemon process will service before terminating voluntarily.

myhostname (see 'postconf -d' output)

The internet hostname of this mail system.

myorigin ($myhostname)

The domain name that locally-posted mail appears to come from, and that locally posted mail is delivered to.

process_id (read-only)

The process ID of a Postfix command or daemon process.

process_name (read-only)

The process name of a Postfix command or daemon process.

queue_directory (see 'postconf -d' output)

The location of the Postfix top-level queue directory.

soft_bounce (no)

Safety net to keep mail queued that would otherwise be returned to the sender.

syslog_facility (mail)

The syslog facility of Postfix logging.

syslog_name (see 'postconf -d' output)

A prefix that is prepended to the process name in syslog records, so that, for example, "smtpd" becomes "prefix/smtpd".

Available in Postfix version 2.1 and later:

enable_original_recipient (yes)

Enable support for the original recipient address after an address is rewritten to a different address (for example with aliasing or with canonical mapping).

Available in Postfix 3.3 and later:

service_name (read-only)

The master.cf service name of a Postfix daemon process.

Available in Postfix 3.5 and later:

info_log_address_format (external)

The email address form that will be used in non-debug logging (info, warning, etc.).

## FILES

```
/etc/postfix/canonical*, canonical mapping table
/etc/postfix/virtual*, virtual mapping table
```

## SEE ALSO

```
trivial-rewrite(8), address rewriting
qmgr(8), queue manager
header_checks(5), message header content inspection
body_checks(5), body parts content inspection
canonical(5), canonical address lookup table format
virtual(5), virtual alias lookup table format
postconf(5), configuration parameters
master(5), generic daemon options
master(8), process manager
postlogd(8), Postfix logging
syslogd(8), system logging
```

## README FILES

```

```

Use "postconf readme_directory" or "postconf html_directory" to locate this information.

```
ADDRESS_REWRITING_README Postfix address manipulation
CONTENT_INSPECTION_README content inspection
```

## LICENSE

```

```

The Secure Mailer license must be distributed with this software.

## AUTHOR(S)

```
Wietse Venema
IBM T.J. Watson Research
P.O. Box 704
Yorktown Heights, NY 10598, USA
Wietse Venema
Google, Inc.
111 8th Avenue
New York, NY 10011, USA
```


discard

title: discard(8)

text:
# discard(8)

## NAME
discard - Postfix discard mail delivery agent

## SYNOPSIS

```
discard [generic Postfix daemon options]
```

## DESCRIPTION

The Postfix discard(8) delivery agent processes delivery requests from the queue manager. Each request specifies a queue file, a sender address, a next-hop destination that is treated as the reason for discarding the mail, and recipient information. The reason may be prefixed with an RFC 3463-compatible detail code. This program expects to be run from the master(8) process manager.

The discard(8) delivery agent pretends to deliver all recipients in the delivery request, logs the "next-hop" destination as the reason for discarding the mail, updates the queue file, and either marks recipients as finished or informs the queue manager that delivery should be tried again at a later time.

Delivery status reports are sent to the trace(8) daemon as appropriate.

## SECURITY

```

```

The discard(8) mailer is not security-sensitive. It does not talk to the network, and can be run chrooted at fixed low privilege.

## STANDARDS

```
RFC 3463 (Enhanced Status Codes)
```

## DIAGNOSTICS

Problems and transactions are logged to syslogd(8) or postlogd(8).

Depending on the setting of the notify_classes parameter, the postmaster is notified of bounces and of other trouble.

## CONFIGURATION PARAMETERS

```

```

Changes to main.cf are picked up automatically as discard(8) processes run for only a limited amount of time. Use the command "postfix reload" to speed up a change.

The text below provides only a parameter summary. See postconf(5) for more details including examples.

config_directory (see 'postconf -d' output)

The default location of the Postfix main.cf and master.cf configuration files.

daemon_timeout (18000s)

How much time a Postfix daemon process may take to handle a request before it is terminated by a built-in watchdog timer.

delay_logging_resolution_limit (2)

The maximal number of digits after the decimal point when logging sub-second delay values.

double_bounce_sender (double-bounce)

The sender address of postmaster notifications that are generated by the mail system.

ipc_timeout (3600s)

The time limit for sending or receiving information over an internal communication channel.

max_idle (100s)

The maximum amount of time that an idle Postfix daemon process waits for an incoming connection before terminating voluntarily.

max_use (100)

The maximal number of incoming connections that a Postfix daemon process will service before terminating voluntarily.

process_id (read-only)

The process ID of a Postfix command or daemon process.

process_name (read-only)

The process name of a Postfix command or daemon process.

queue_directory (see 'postconf -d' output)

The location of the Postfix top-level queue directory.

syslog_facility (mail)

The syslog facility of Postfix logging.

syslog_name (see 'postconf -d' output)

A prefix that is prepended to the process name in syslog records, so that, for example, "smtpd" becomes "prefix/smtpd".

Available in Postfix 3.3 and later:

service_name (read-only)

The master.cf service name of a Postfix daemon process.

## SEE ALSO

```
qmgr(8), queue manager
bounce(8), delivery status reports
error(8), Postfix error delivery agent
postconf(5), configuration parameters
master(5), generic daemon options
master(8), process manager
postlogd(8), Postfix logging
syslogd(8), system logging
```

## LICENSE

```

```

The Secure Mailer license must be distributed with this software.

## HISTORY

This service was introduced with Postfix version 2.2.

## AUTHOR(S)

```
Victor Duchovni
Morgan Stanley
Based on code by:
Wietse Venema
IBM T.J. Watson Research
P.O. Box 704
Yorktown Heights, NY 10598, USA
Wietse Venema
Google, Inc.
111 8th Avenue
New York, NY 10011, USA
```


dnsblog

title: dnsblog(8)

text:
# dnsblog(8)

## NAME
dnsblog - Postfix DNS allow/denylist logger

## SYNOPSIS

```
dnsblog [generic Postfix daemon options]
```

## DESCRIPTION

The dnsblog(8) server implements an ad-hoc DNS allow/denylist lookup service. This may eventually be replaced by an UDP client that is built directly into the postscreen(8) server.

## PROTOCOL

```

```

With each connection, the dnsblog(8) server receives a DNS allow/denylist domain name, an IP address, and an ID. If the IP address is listed under the DNS allow/denylist, the dnsblog(8) server logs the match and replies with the query arguments plus an address list with the resulting IP addresses, separated by whitespace, and the reply TTL. Otherwise it replies with the query arguments plus an empty address list and the reply TTL; the reply TTL is -1 if there is no reply, or a negative reply that contains no SOA record. Finally, the dnsblog(8) server closes the connection.

## DIAGNOSTICS

Problems and transactions are logged to syslogd(8) or postlogd(8).

## CONFIGURATION PARAMETERS

```

```

Changes to main.cf are picked up automatically, as dnsblog(8) processes run for only a limited amount of time. Use the command "postfix reload" to speed up a change.

The text below provides only a parameter summary. See postconf(5) for more details including examples.

config_directory (see 'postconf -d' output)

The default location of the Postfix main.cf and master.cf configuration files.

daemon_timeout (18000s)

How much time a Postfix daemon process may take to handle a request before it is terminated by a built-in watchdog timer.

postscreen_dnsbl_sites (empty)

Optional list of DNS allow/denylist domains, filters and weight factors.

ipc_timeout (3600s)

The time limit for sending or receiving information over an internal communication channel.

process_id (read-only)

The process ID of a Postfix command or daemon process.

process_name (read-only)

The process name of a Postfix command or daemon process.

queue_directory (see 'postconf -d' output)

The location of the Postfix top-level queue directory.

syslog_facility (mail)

The syslog facility of Postfix logging.

syslog_name (see 'postconf -d' output)

A prefix that is prepended to the process name in syslog records, so that, for example, "smtpd" becomes "prefix/smtpd".

Available in Postfix 3.3 and later:

service_name (read-only)

The master.cf service name of a Postfix daemon process.

## SEE ALSO

```
smtpd(8), Postfix SMTP server
postconf(5), configuration parameters
postlogd(8), Postfix logging
syslogd(8), system logging
```

## LICENSE

```

```

The Secure Mailer license must be distributed with this software.

## HISTORY

This service was introduced with Postfix version 2.8.

## AUTHOR(S)

```
Wietse Venema
IBM T.J. Watson Research
P.O. Box 704
Yorktown Heights, NY 10598, USA
Wietse Venema
Google, Inc.
111 8th Avenue
New York, NY 10011, USA
```


error

title: error(8)

text:
# error(8)

## NAME
error - Postfix error/retry mail delivery agent

## SYNOPSIS

```
error [generic Postfix daemon options]
```

## DESCRIPTION

The Postfix error(8) delivery agent processes delivery requests from the queue manager. Each request specifies a queue file, a sender address, the reason for non-delivery (specified as the next-hop destination), and recipient information. The reason may be prefixed with an RFC 3463-compatible detail code; if none is specified a default 4.0.0 or 5.0.0 code is used instead. This program expects to be run from the master(8) process manager.

Depending on the service name in master.cf, error or retry, the server bounces or defers all recipients in the delivery request using the "next-hop" information as the reason for non-delivery. The retry service name is supported as of Postfix 2.4.

Delivery status reports are sent to the bounce(8), defer(8) or trace(8) daemon as appropriate.

## SECURITY

```

```

The error(8) mailer is not security-sensitive. It does not talk to the network, and can be run chrooted at fixed low privilege.

## STANDARDS

```
RFC 3463 (Enhanced Status Codes)
```

## DIAGNOSTICS

Problems and transactions are logged to syslogd(8) or postlogd(8).

Depending on the setting of the notify_classes parameter, the postmaster is notified of bounces and of other trouble.

## CONFIGURATION PARAMETERS

```

```

Changes to main.cf are picked up automatically as error(8) processes run for only a limited amount of time. Use the command "postfix reload" to speed up a change.

The text below provides only a parameter summary. See postconf(5) for more details including examples.

2bounce_notice_recipient (postmaster)

The recipient of undeliverable mail that cannot be returned to the sender.

bounce_notice_recipient (postmaster)

The recipient of postmaster notifications with the message headers of mail that Postfix did not deliver and of SMTP conversation transcripts of mail that Postfix did not receive.

config_directory (see 'postconf -d' output)

The default location of the Postfix main.cf and master.cf configuration files.

daemon_timeout (18000s)

How much time a Postfix daemon process may take to handle a request before it is terminated by a built-in watchdog timer.

delay_logging_resolution_limit (2)

The maximal number of digits after the decimal point when logging sub-second delay values.

double_bounce_sender (double-bounce)

The sender address of postmaster notifications that are generated by the mail system.

ipc_timeout (3600s)

The time limit for sending or receiving information over an internal communication channel.

max_idle (100s)

The maximum amount of time that an idle Postfix daemon process waits for an incoming connection before terminating voluntarily.

max_use (100)

The maximal number of incoming connections that a Postfix daemon process will service before terminating voluntarily.

notify_classes (resource, software)

The list of error classes that are reported to the postmaster.

process_id (read-only)

The process ID of a Postfix command or daemon process.

process_name (read-only)

The process name of a Postfix command or daemon process.

queue_directory (see 'postconf -d' output)

The location of the Postfix top-level queue directory.

syslog_facility (mail)

The syslog facility of Postfix logging.

syslog_name (see 'postconf -d' output)

A prefix that is prepended to the process name in syslog records, so that, for example, "smtpd" becomes "prefix/smtpd".

Available in Postfix 3.3 and later:

service_name (read-only)

The master.cf service name of a Postfix daemon process.

## SEE ALSO

```
qmgr(8), queue manager
bounce(8), delivery status reports
discard(8), Postfix discard delivery agent
postconf(5), configuration parameters
master(5), generic daemon options
master(8), process manager
postlogd(8), Postfix logging
syslogd(8), system logging
```

## LICENSE

```

```

The Secure Mailer license must be distributed with this software.

## AUTHOR(S)

```
Wietse Venema
IBM T.J. Watson Research
P.O. Box 704
Yorktown Heights, NY 10598, USA
Wietse Venema
Google, Inc.
111 8th Avenue
New York, NY 10011, USA
```


flush

title: flush(8)

text:
# flush(8)

## NAME
flush - Postfix fast flush server

## SYNOPSIS

```
flush [generic Postfix daemon options]
```

## DESCRIPTION

The flush(8) server maintains a record of deferred mail by destination. This information is used to improve the performance of the SMTP ETRN request, and of its command-line equivalent, "sendmail -qR" or "postqueue -f". This program expects to be run from the master(8) process manager.

The record is implemented as a per-destination logfile with as contents the queue IDs of deferred mail. A logfile is append-only, and is truncated when delivery is requested for the corresponding destination. A destination is the part on the right-hand side of the right-most @ in an email address.

Per-destination logfiles of deferred mail are maintained only for eligible destinations. The list of eligible destinations is specified with the fast_flush_domains configuration parameter, which defaults to $relay_domains.

This server implements the following requests:

add sitename queueid

Inform the flush(8) server that the message with the specified queue ID is queued for the specified destination.

send_site sitename

Request delivery of mail that is queued for the specified destination.

send_file queueid

Request delivery of the specified deferred message.

refresh

Refresh non-empty per-destination logfiles that were not read in $fast_flush_refresh_time hours, by simulating send requests (see above) for the corresponding destinations. Delete empty per-destination logfiles that were not updated in $fast_flush_purge_time days.

This request completes in the background.

purge

Do a refresh for all per-destination logfiles.

## SECURITY

```

```

The flush(8) server is not security-sensitive. It does not talk to the network, and it does not talk to local users. The fast flush server can run chrooted at fixed low privilege.

## DIAGNOSTICS

Problems and transactions are logged to syslogd(8) or postlogd(8).

## BUGS

Fast flush logfiles are truncated only after a "send" request, not when mail is actually delivered, and therefore can accumulate outdated or redundant data. In order to maintain sanity, "refresh" must be executed periodically. This can be automated with a suitable wakeup timer setting in the master.cf configuration file.

Upon receipt of a request to deliver mail for an eligible destination, the flush(8) server requests delivery of all messages that are listed in that destination's logfile, regardless of the recipients of those messages. This is not an issue for mail that is sent to a relay_domains destination because such mail typically only has recipients in one domain.

## CONFIGURATION PARAMETERS

```

```

Changes to main.cf are picked up automatically as flush(8) processes run for only a limited amount of time. Use the command "postfix reload" to speed up a change.

The text below provides only a parameter summary. See postconf(5) for more details including examples.

config_directory (see 'postconf -d' output)

The default location of the Postfix main.cf and master.cf configuration files.

daemon_timeout (18000s)

How much time a Postfix daemon process may take to handle a request before it is terminated by a built-in watchdog timer.

fast_flush_domains ($relay_domains)

Optional list of destinations that are eligible for per-destination logfiles with mail that is queued to those destinations.

fast_flush_refresh_time (12h)

The time after which a non-empty but unread per-destination "fast flush" logfile needs to be refreshed.

fast_flush_purge_time (7d)

The time after which an empty per-destination "fast flush" logfile is deleted.

ipc_timeout (3600s)

The time limit for sending or receiving information over an internal communication channel.

max_idle (100s)

The maximum amount of time that an idle Postfix daemon process waits for an incoming connection before terminating voluntarily.

max_use (100)

The maximal number of incoming connections that a Postfix daemon process will service before terminating voluntarily.

parent_domain_matches_subdomains (see 'postconf -d' output)

A list of Postfix features where the pattern "example.com" also matches subdomains of example.com, instead of requiring an explicit ".example.com" pattern.

process_id (read-only)

The process ID of a Postfix command or daemon process.

process_name (read-only)

The process name of a Postfix command or daemon process.

queue_directory (see 'postconf -d' output)

The location of the Postfix top-level queue directory.

syslog_facility (mail)

The syslog facility of Postfix logging.

syslog_name (see 'postconf -d' output)

A prefix that is prepended to the process name in syslog records, so that, for example, "smtpd" becomes "prefix/smtpd".

Available in Postfix 3.3 and later:

service_name (read-only)

The master.cf service name of a Postfix daemon process.

## FILES

```
/var/spool/postfix/flush, "fast flush" logfiles.
```

## SEE ALSO

```
smtpd(8), SMTP server
qmgr(8), queue manager
postconf(5), configuration parameters
master(5), generic daemon options
master(8), process manager
postlogd(8), Postfix logging
syslogd(8), system logging
```

## README FILES

```

```

Use "postconf readme_directory" or "postconf html_directory" to locate this information.

```
ETRN_README, Postfix ETRN howto
```

## LICENSE

```

```

The Secure Mailer license must be distributed with this software.

## HISTORY

This service was introduced with Postfix version 1.0.

## AUTHOR(S)

```
Wietse Venema
IBM T.J. Watson Research
P.O. Box 704
Yorktown Heights, NY 10598, USA
Wietse Venema
Google, Inc.
111 8th Avenue
New York, NY 10011, USA
```