maddy

  1# MAIL FROM and From authorization
  2
  3Module check.authorize_sender verifies that envelope and header sender addresses belong
  4to the authenticated user. Address ownership is established via table
  5that maps each user account to a email address it is allowed to use.
  6There are some special cases, see `user_to_email` description below.
  7
  8```
  9check.authorize_sender {
 10    prepare_email identity
 11    user_to_email identity
 12    check_header yes
 13
 14    unauth_action reject
 15    no_match_action reject
 16    malformed_action reject
 17    err_action reject
 18
 19    auth_normalize auto
 20    from_normalize auto
 21}
 22```
 23```
 24check {
 25    authorize_sender { ... }
 26}
 27```
 28
 29## Configuration directives
 30
 31### user_to_email _table_
 32Default: `identity`
 33
 34Table that maps authorization username to the list of sender emails
 35the user is allowed to use.
 36
 37In additional to email addresses, the table can contain domain names or
 38special string "\*" as a value. If the value is a domain - user
 39will be allowed to use any mailbox within it as a sender address.
 40If it is "\*" - user will be allowed to use any address.
 41
 42By default, table.identity is used, meaning that username should
 43be equal to the sender email.
 44
 45Before username is looked up via the table, normalization algorithm
 46defined by auth_normalize is applied to it.
 47
 48---
 49
 50### prepare_email _table_
 51Default: `identity`
 52
 53Table that is used to translate email addresses before they
 54are matched against user_to_email values.
 55
 56Typically used to allow users to use their aliases as sender
 57addresses - prepare_email in this case should translate
 58aliases to "canonical" addresses. This is how it is
 59done in default configuration.
 60
 61If table does not contain any mapping for the used sender
 62address, it will be used as is.
 63
 64---
 65
 66### check_header _boolean_
 67Default: `yes`
 68
 69Whether to verify header sender in addition to envelope.
 70
 71Either Sender or From field value should match the
 72authorization identity.
 73
 74---
 75
 76### unauth_action _action_
 77Default: `reject`
 78
 79What to do if the user is not authenticated at all.
 80
 81---
 82
 83### no_match_action _action_
 84Default: `reject`
 85
 86What to do if user is not allowed to use the sender address specified.
 87
 88---
 89
 90### malformed_action _action_
 91Default: `reject`
 92
 93What to do if From or Sender header fields contain malformed values.
 94
 95---
 96
 97### err_action _action_
 98Default: `reject`
 99
100What to do if error happens during prepare_email or user_to_email lookup.
101
102---
103
104### auth_normalize _action_
105Default: `auto`
106
107Normalization function to apply to authorization username before
108further processing.
109
110Available options:
111
112- `auto`                    `precis_casefold_email` for valid emails, `precis_casefold` otherwise.
113- `precis_casefold_email`   PRECIS UsernameCaseMapped profile + U-labels form for domain
114- `precis_casefold`         PRECIS UsernameCaseMapped profile for the entire string
115- `precis_email`            PRECIS UsernameCasePreserved profile + U-labels form for domain
116- `precis`                  PRECIS UsernameCasePreserved profile for the entire string
117- `casefold`                Convert to lower case
118- `noop`                    Nothing
119
120PRECIS profiles are defined by RFC 8265. In short, they make sure
121that Unicode strings that look the same will be compared as if they were
122the same. CaseMapped profiles also convert strings to lower case.
123
124---
125
126### from_normalize _action_
127Default: `auto`
128
129Normalization function to apply to email addresses before
130further processing.
131
132Available options are same as for `auth_normalize`.