| 192 |
- |
1 |
##
|
|
|
2 |
## Settings specific to SMTP Submission
|
|
|
3 |
##
|
|
|
4 |
|
|
|
5 |
# SMTP Submission logout format string:
|
|
|
6 |
# %i - total number of bytes read from client
|
|
|
7 |
# %o - total number of bytes sent to client
|
|
|
8 |
# %{command_count} - Number of commands received from client
|
|
|
9 |
# %{reply_count} - Number of replies sent to client
|
|
|
10 |
# %{session} - Session ID of the login session
|
|
|
11 |
# %{transaction_id} - ID of the current transaction, if any
|
|
|
12 |
#submission_logout_format = in=%i out=%o
|
|
|
13 |
|
|
|
14 |
# Host name reported by the SMTP service, for example to the client in the
|
|
|
15 |
# initial greeting and to the relay server in the HELO/EHLO command.
|
|
|
16 |
# Default is the system's real hostname@domain.
|
|
|
17 |
#hostname =
|
|
|
18 |
|
|
|
19 |
# Maximum size of messages accepted for relay. This announced in the SIZE
|
|
|
20 |
# capability. If not configured, this is either determined from the relay
|
|
|
21 |
# server or left unlimited if no limit is known (relay will reply with error
|
|
|
22 |
# if some unknown limit exists there, which is duly passed to our client).
|
|
|
23 |
#submission_max_mail_size =
|
|
|
24 |
|
|
|
25 |
# Maximum number of recipients accepted per connection (default: unlimited)
|
|
|
26 |
#submission_max_recipients =
|
|
|
27 |
|
|
|
28 |
# Workarounds for various client bugs:
|
|
|
29 |
# whitespace-before-path:
|
|
|
30 |
# Allow one or more spaces or tabs between `MAIL FROM:' and path and between
|
|
|
31 |
# `RCPT TO:' and path.
|
|
|
32 |
# mailbox-for-path:
|
|
|
33 |
# Allow using bare Mailbox syntax (i.e., without <...>) instead of full path
|
|
|
34 |
# syntax.
|
|
|
35 |
#
|
|
|
36 |
# The list is space-separated.
|
|
|
37 |
#submission_client_workarounds =
|
|
|
38 |
|
|
|
39 |
# Relay server configuration:
|
|
|
40 |
#
|
|
|
41 |
# The Dovecot SMTP submission service directly proxies the mail transaction
|
|
|
42 |
# to the SMTP relay configured here.
|
|
|
43 |
|
|
|
44 |
# Host name for the relay server (required)
|
|
|
45 |
#submission_relay_host =
|
|
|
46 |
|
|
|
47 |
# Port for the relay server
|
|
|
48 |
#submission_relay_port = 25
|
|
|
49 |
|
|
|
50 |
# Is the relay server trusted? This determines whether we try to send
|
|
|
51 |
# (Postfix-specific) XCLIENT data to the relay server
|
|
|
52 |
#submission_relay_trusted = no
|
|
|
53 |
|
|
|
54 |
# Authentication data for the relay server if authentication is required
|
|
|
55 |
#submission_relay_user =
|
|
|
56 |
#submission_relay_master_user =
|
|
|
57 |
#submission_relay_password =
|
|
|
58 |
|
|
|
59 |
# SSL configuration for connection to relay server
|
|
|
60 |
#
|
|
|
61 |
# submission_relay_ssl:
|
|
|
62 |
# Indicates whether SSL is used for the connection to the relay server. The
|
|
|
63 |
# following values are defined for this setting:
|
|
|
64 |
#
|
|
|
65 |
# no - No SSL is used
|
|
|
66 |
# smtps - An SMTPS connection (immediate SSL) is used
|
|
|
67 |
# starttls - The STARTTLS command is used to establish SSL layer
|
|
|
68 |
#submission_relay_ssl = no
|
|
|
69 |
|
|
|
70 |
# submission_relay_ssl_verify:
|
|
|
71 |
# Configures whether the SSL certificate of the relay server is to be
|
|
|
72 |
# verified.
|
|
|
73 |
#submission_relay_ssl_verify = yes
|
|
|
74 |
|
|
|
75 |
# Write protocol logs for relay connection to this directory for debugging
|
|
|
76 |
#submission_relay_rawlog_dir =
|
|
|
77 |
|
|
|
78 |
# BURL is configured implicitly by IMAP URLAUTH
|
|
|
79 |
|
|
|
80 |
# Part of the SMTP capabilities that the submission service can offer to the
|
|
|
81 |
# client (as listed in the EHLO reply) depend on those capabilities also being
|
|
|
82 |
# provided by the relay server. These capabilities currently are:
|
|
|
83 |
#
|
|
|
84 |
# - 8BITMIME
|
|
|
85 |
# - BINARYMIME
|
|
|
86 |
# - DSN
|
|
|
87 |
# - VRFY (always returns 252 without support)
|
|
|
88 |
#
|
|
|
89 |
# By default, the submission service first connects to the relay server to
|
|
|
90 |
# determine the support for such capabilities before sending the initial EHLO
|
|
|
91 |
# reply to the client. If the list of capabilities returned by the relay server
|
|
|
92 |
# is somehow unreliable or it is undesirable to start the connection to the
|
|
|
93 |
# relay server before the first mail transaction is started, the backend
|
|
|
94 |
# capabilities can be configured explicitly using the
|
|
|
95 |
# submission_backend_capabilities setting. This is a space-separated list of
|
|
|
96 |
# SMTP capability names. This setting is only relevant for capabilities that
|
|
|
97 |
# depend on support from the relay server: including (or omitting) capabilities
|
|
|
98 |
# that are not listed above has no effect. When this setting is explicitly set
|
|
|
99 |
# to the empty string, none of the capabilities is enabled. To achieve the
|
|
|
100 |
# default behavior, this setting must be left unconfigured.
|
|
|
101 |
#submission_backend_capabilities =
|
|
|
102 |
|
|
|
103 |
protocol submission {
|
|
|
104 |
# Space-separated list of plugins to load (default is global mail_plugins).
|
|
|
105 |
#mail_plugins = $mail_plugins
|
|
|
106 |
|
|
|
107 |
# Maximum number of SMTP submission connections allowed for a user from
|
|
|
108 |
# each IP address.
|
|
|
109 |
# NOTE: The username is compared case-sensitively.
|
|
|
110 |
#mail_max_userip_connections = 10
|
|
|
111 |
}
|
|
|
112 |
|