blob: 1021e8f9b3b3ff3aeceb17f833edfc8be105004c (
plain)
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
|
<!--
$FML: post_permit_anyone.sgml,v 1.6 2005/12/14 12:43:52 fukachan Exp $
$jaFML: post_permit_anyone.sgml,v 1.3 2003/04/15 14:51:37 fukachan Exp $
-->
<sect1 id="config.post.permitanyone">
<title>
Case Study: Anyone Can Post.
</title>
<para>
<screen>
article_post_restrictions = permit_anyone
</screen>
$article_post_restrictions parameter controls who can post to this ML.
To set this as "permit_anyone", anybody (including system special
account e.g. root, postmaster) can post.
</para>
<para>
By default, $article_post_restrictions is defined as follows for
&fml4; compatibility,
<screen>
article_post_restrictions = reject_system_special_accounts
permit_member_maps
reject
</screen>
"reject_system_special_accounts" denies post if
From: looks like system accounts e.g. root, postmaster.
</para>
<para>
This configuration means that system special accounts cannot post and
only user contained in $member_maps can post article.
</para>
<para>
Attention that reject_XXX and permit_XXX statement is first match.
</para>
<sect2 id="recipes.config.post.permitanyone">
<title>
recipes
</title>
<qandaset>
<qandaentry>
<question>
<para>
Any persons in a domain can post always.
</para>
</question>
<answer>
<para>
It is not easy to handle global variables in the case of &fml4; .
</para>
<para>
By using the following restriction, you can ermit only sender of
example.co.jp domain and reject other domain.
<screen>
[/var/spool/ml/elena/config.cf]
article_post_restrictions = reject_system_special_accounts
permit_member_maps
reject
member_maps = pcre:$ml_home_dir/sender.pcre
[$ml_home_dir/domains]
\S+\@example.co.jp
</screen>
</para>
</answer>
</qandaentry>
</qandaset>
</sect2>
</sect1>
|
