Circa 2002-Mar-28 09:59:41 +0000 dixit Drav Sloan:
: Jim Knoble wrote:
: > You might wish this to be:
: > command = "/usr/bin/procmail -d ${local_part}"
:
: This has not been an issue for me, and I have ran it like this for a
: couple of years now.
If it works for you, fine. Exim is configurable enough that not
everyone's Exim works the same, though.
: > You'll also want at least:
: >
: > return_fail_output = false
: > return_output = false
:
: Umm this seems to be missing from the 3.x specification, whats it
: meant to do, stop any bounces? Isn't that a bit facist?
In the exim-3.35 spec.txt (reformatted for legibility):
18.1 Returned status and data
If the command exits with a non-zero return code, the delivery is
deemed to have failed, unless either the "ignore_status" option is
set (in which case the return code is treated as zero), or the
return code is one of those listed in the "temp_errors" option,
which are interpreted as meaning 'try again later'. In this case,
delivery is deferred.
If the return code is greater than 128 and the command being run is
a shell script, it normally means that the script was terminated by
a signal whose value is the return code minus 128.
The "return_output" option can affect the result of a pipe
^^^^^^^^^^^^^^^
delivery. If it is set and the command produces any output on its
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
standard output or standard error files, it is considered to have
^^^^^^^^^^^^^^^^^^^^^^^^^^
failed, even if it gave a zero return code or if "ignore_status" is
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
set. The output from the command is sent as part of the delivery
^^^^^
failure report. However, if "return_fail_output" is set, output is
returned only when the command exits with a failure return code,
that is, a value other than zero or a code that matches
"temp_errors".
This basically prevents temporarily broken procmailrc's from causing
unnecessary bounces; the message is deferred, and delivery is attempted
according to the usual retry rules. If the retries time out, the
message bounces. It's not fascist at all---it's actually rather
resilient to transient failure.
A good analogy might be delivery to mailboxes on an NFS-mounted
filesystem. If the NFS server is down temporarily, should messages to
those mailboxes bounce? No, they should be deferred. If the NFS
server isn't back after the maximum retry time, then fine, bounce them.
: I've not seen or had any issues with the setup I passed to the list.
Your needs and usage patters may be different than others'.
: > and potentially also:
: >
: > # Add useful headers
: > delivery_date_add = true
: > envelope_to_add = true
: >
: > # Keep someone's broken procmailrc from filling up your logs
: > log_defer_output = false
: > log_fail_output = false
: > log_output = false
:
: And never know that anything is broke...
Only if you care. Some admins might think that broken procmailrc's are
the user's problem. If a user doesn't get any mail for a day or two,
he or she can complain to the admin....
: > # Keep procmail from making group- or world-writeable files
: > umask = 0022
: >
: > # Use this only if you have group-writeable mailboxes;
: > # for mailboxes in a sticky directory, remove it.
: > group = mail
:
: Only if that user so chooses to have all this addition gumpph. :-)
The method of delivery to mailboxes (group-writeable or sticky
directory) is not generally up to the user, but to the admin. And
while the admin may not care whether users' email is kept private from
other users on the system, he certainly ought to care whether procmail
is capable of creating, for example, world-writable ~/.rhosts files, no?
Note that all of the things you complain about i couched as
suggestions, not as "you must do things this way". If you don't want
to, then fine. Just don't get so worked up about it.
--
jim knoble | jmknoble@??? |
http://www.pobox.com/~jmknoble/
(GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491)
