1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
|
New Features in Exim
--------------------
This file contains descriptions of new features that have been added to Exim,
but have not yet made it into the main manual (which is most conveniently
updated when there is a relatively large batch of changes). The ChangeLog file
contains a brief listing of *all* changes, including bug fixes.
When the manual is up-to-date with the code and there have been a lot of recent
changes, the more important ones may be listed here for convenient reference.
Otherwise this file will contain just these two introductory paragraphs.
Version 2.05
------------
1. The option check_dns_names has been renamed dns_check_names for uniformity.
The old name remains as a synonym.
2. When verification of an incoming sender address suffers a temporary error,
Exim now remembers this in a hints database, as for permanent errors.
Subsequent errors from the same host within 24 hours then cause a 4xx error to
MAIL FROM instead of after DATA. This reduces the data on the reject log and
also the amount repeatedly transferred over the net.
3. If sender_verify_max_retry_rate is set greater than zero, and the rate of
temporary rejection of a specific incoming sender address from a specific host,
in units of rejections per hour, exceeds it, the temporary error is converted
into a permanent verification error. This should help in stopping hosts
hammering too frequently with temporarily failing sender addresses, and might
help reduce spam. The default value of the option is 12, which means that a
sender address that has a temporary verification error more than once every 5
minutes will eventually get permanently rejected. Once permanent rejection has
been triggered, subsequent temporary failures will all cause permanent errors,
until there has been an interval of at least 24 hours since the last failure.
After 24 hours, the hint expires.
4. A consequence of 2 and 3 is that there is a new field in the reject hints
database, which is the rate of temporary rejection for a given sender at a
given host. This is shown as a number with one decimal place after the T or F
flag in each line of output from exim_dumpdb or exim_fixdb. A value of zero is
used after a permanent rejection has been given, either because of a permanent
verification error, or because of too many temporary errors.
5. Changes have been made to outgoing SMTP delivery when a temporary SMTP
error occurs. Previously no error recording happened, and the message would be
tried again at the next queue run. The error is now remembered for the
recipient address as a kind of routing or directing defer. The address won't
get tried again until the appropriate time has passed. This applies to 4xx
errors given to RCPT TO, and also to 4xx errors on MAIL FROM, DATA, and ".". In
all cases other than RCPT TO, the error is deemed to apply to all recipient
addresses, and so multiple retry records get created.
6. Entries in the log, at level 4, are now made when an incoming SMTP message
doesn't get delivered immediately because of load level or number of
connections or number of messages in one connection.
Version 2.03
------------
1. There's a new utility called exim_lock, which can be used to lock a mailbox
file using the same algorithm as Exim uses. This can be used to prevent any
modification of a mailbox by Exim or a user agent while investigating a
problem. The utility requires the name of the file as its first argument. If
the locking is successful, the second argument is run as a command (using C's
system() function); if there is no second argument, the value of the SHELL
environment variable is used; if this is unset or empty, /bin/sh is run. When
the command finishes, the mailbox is unlocked and the utility ends. The
following options are available:
-fcntl use fcntl() locking
-lockfile create a lock file
-v give verbose output
-q suppress verification output
If neither -fcntl nor -lockfile is given, both forms of locking are applied;
this is what Exim does by default. The use of -fcntl requires that the file be
writeable; the use of -lockfile requires that the directory containing the file
be writeable. Locking by lock file does not last for ever; Exim assumes that a
lock file is expired if it is more than 30 minutes old.
The default output contains verification of the locking that takes place. The
-v option causes some additional information to be given. The -q option
suppresses all output except error messages.
Examples:
exim_lock /var/spool/mail/spqr
runs an interactive shell while the file is locked, while
exim_lock -q /var/spool/mail/spqr <<End
<some commands>
End
runs a specific non-interactive sequence of commands while the file is locked,
suppressing all verification output. A single command can be run by a command
such as
exim_lock -q /var/spool/mail/spqr "cp /var/spool/mail/spqr /some/where"
Note that if a command is supplied, it must be entirely contained within the
second argument - hence the quotes.
2. The option smtp_accept_queue_per_connection (default value 10) limits the
number of delivery processes that Exim starts automatically when receiving
messages via SMTP. If the value of the option is greater than zero, and the
number of messages received in a single SMTP session exceeds this number,
subsequent messages are placed on the spool, but no delivery process is
started. This helps to limit the number of Exim processes when a server
restarts after downtime and there is a lot of mail waiting for it on other
systems. See also smtp_accept_queue.
3. The option smtp_log_connections turns on more verbose logging of
connections, at log level 4. This does not apply to batch SMTP, but it does
apply to SMTP connections from local processes that use the -bs option. A log
line is written whenever a connection is established or closed. If a
connection is dropped in the middle of a message, a log line is always
written, but otherwise nothing is written at the start and end of connections
unless log_connections is set.
4. If :fail: or :defer: in an alias file has a non-empty message associated
with it, this is now used in the SMTP response when verification fails
during a RCPT TO or VRFY command.
5. If -oMt "" is given, the sender ident field is unset.
End
|
