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
130
131
132
133
134
135
136
137
138
139
140
141
142
|
From: Santiago Vila <sanvila@debian.org>
Subject: The system-wide mail directory is /var/mail as per policy
X-Debian-version: 3.22-2
--- a/FAQ
+++ b/FAQ
@@ -57,8 +57,8 @@
Forward to |/usr/bin/procmail
or if that doesn't work, try:
Pipe to /usr/bin/procmail
- as the only line in your mail spool file (e.g. /usr/mail/$LOGNAME), as
- well as doing a "chmod 06660 /usr/mail/$LOGNAME". For more information
+ as the only line in your mail spool file (e.g. /var/mail/$LOGNAME), as
+ well as doing a "chmod 06660 /var/mail/$LOGNAME". For more information
on such systems, do a "man mail".
If all of this doesn't work, procmail can be called on a periodical
@@ -210,14 +210,14 @@
procmail with both the fcntl() and lockf() locking method
disabled (see config.h).
-17. I sometimes get these `Lock failure on "/usr/mail/$LOGNAME.lock"' errors
+17. I sometimes get these `Lock failure on "/var/mail/$LOGNAME.lock"' errors
from procmail. What do I do about it?
The problem here is that as long as procmail has not read a
$HOME/.procmailrc file, it can hang on to the sgid mail permission
- (which it needs in order to create a lockfile in /usr/mail).
+ (which it needs in order to create a lockfile in /var/mail).
I.e. if procmail delivers mail to a user without a $HOME/.procmailrc
- file, procmail *can* (and does) use the /usr/mail/$LOGNAME.lock file.
+ file, procmail *can* (and does) use the /var/mail/$LOGNAME.lock file.
If, however, it finds a $HOME/.procmailrc file, procmail has to let go
of the sgid mail permission because otherwise any ordinary user could
@@ -226,7 +226,7 @@
There are several solutions to this problem:
- Some systems support the sticky bit on directories (when set only
allows the owner of a file in that directory to rename or remove
- it). This enables you to make /usr/spool/mail drwxrwxrwt. It is
+ it). This enables you to make /var/mail drwxrwxrwt. It is
thus effectively world writable, but all the mailboxes in it are
protected because only the mailbox owner can remove or rename it.
- If your system did not exhibit the !@#$%^&* POSIX semantics for
@@ -245,9 +245,9 @@
:0
$DEFAULT
- - You could, instead of using /usr/mail/$LOGNAME, use a file below
+ - You could, instead of using /var/mail/$LOGNAME, use a file below
your home directory as your default mailbox.
- - Or, you could still use /usr/mail/$LOGNAME as the mailbox, but
+ - Or, you could still use /var/mail/$LOGNAME as the mailbox, but
simply instruct procmail to use a different lockfile. This can
be achieved by putting following recipe at the bottom of
your .procmailrc file:
--- a/FEATURES
+++ b/FEATURES
@@ -30,7 +30,7 @@
per message, the similar MH directory folders (numbered files),
and Maildir directory folders (a multi-directory format that requires
no locking)
- + Native support for /var/spool/mail/b/a/bar type mailspools
+ + Native support for /var/mail/b/a/bar type mailspools
+ Variable assignment and substitution is an extremely complete subset
of the standard /bin/sh syntax
+ Provides a mail log file, which logs all mail arrival, shows
--- a/examples/advanced
+++ b/examples/advanced
@@ -251,14 +251,14 @@
--------------------------------------------------------
There are many different reasons why more and more sites decide not to
-store mail in /usr/spool/mail or /usr/mail anymore.
+store mail in /var/spool/mail or /var/mail anymore.
Some of the obvious advantages when storing mail in the recipient's home
directory are:
- Mail is automatically subject to the user's quota limitations.
- Often there is more room on the home partition(s) than on that
- one /usr/mail partition.
+ one /var/mail partition.
-The quota limitations also apply to /usr/spool/mail or /usr/mail if procmail
+The quota limitations also apply to /var/spool/mail or /var/mail if procmail
does the delivery. These quota limitations often do not work with the
regular /bin/mail since that usually writes the mailbox with root permissions
(eluding the quota restrictions).
@@ -276,7 +276,7 @@
defined SYSTEM_MBOX to be. Some braindamaged mail programs
do not pick up the MAIL environment variable, these either
have to be patched/recompiled or you have to create symbolic
- links in /usr/mail to every person's new mailbox.
+ links in /var/mail to every person's new mailbox.
---
--- a/src/authenticate.c
+++ b/src/authenticate.c
@@ -39,13 +39,13 @@
#include "authenticate.h"
#ifndef MAILSPOOLDIR
-#define MAILSPOOLDIR "/var/spool/mail/" /* watch the trailing / */
+#define MAILSPOOLDIR "/var/mail/" /* watch the trailing / */
#endif
#ifndef MAILSPOOLSUFFIX
#define MAILSPOOLSUFFIX "" /* suffix to force maildir or MH style */
#endif
#ifndef MAILSPOOLHASH
-#define MAILSPOOLHASH 0 /* 2 would deliver to /var/spool/mail/b/a/bar */
+#define MAILSPOOLHASH 0 /* 2 would deliver to /var/mail/b/a/bar */
#endif
/*#define MAILSPOOLHOME "/.mail" /* watch the leading / */
/* delivers to $HOME/.mail */
--- a/src/autoconf
+++ b/src/autoconf
@@ -89,7 +89,7 @@
# #define NOfcntl_lock
#Ok #define USElockf
#Ok #define USEflock
-#Ok #define MAILSPOOLDIR "/var/spool/mail/"
+#Ok #define MAILSPOOLDIR "/var/mail/"
#Ok #define SENDMAIL "/usr/sbin/sendmail"
# #define buggy_SENDMAIL
# #define DEFflagsendmail ""
@@ -1416,14 +1416,14 @@
found=no
-for a in /var/spool/mail /usr/spool/mail /var/mail /usr/mail /spool/mail
+for a in /var/mail /var/spool/mail /usr/spool/mail /usr/mail /spool/mail
do
test -d $a -a $found != yes &&
echo '#define MAILSPOOLDIR "'$a'/"' >>$ACONF && found=yes
done
if test $found != yes
then
- echo '#define MAILSPOOLDIR "/var/spool/mail/"' >>$ACONF
+ echo '#define MAILSPOOLDIR "/var/mail/"' >>$ACONF
echo Could not find the system-mailbox directory, supplied default.
fi
|
