blob: d2b3a2d3a06dd05f4a0953611488912e5cd0ffe7 (
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
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
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
|
<!--
$FML: post_check_article_thread.sgml,v 1.2 2005/09/24 13:53:41 fukachan Exp $
$jaFML: post_check_article_thread.sgml,v 1.3 2005/06/25 14:12:52 fukachan Exp $
-->
<sect1 id="config.post.check.article.thread">
<title>
Case Study: Article Posting Allowd If It Is A Reply To The Former One.
</title>
<para>
From time to time we can find that a posted article is denied due to
posting from not a member.
</para>
<para>
One reason is that the member who replied some article forgot to
notify changes of his/her mail address to the mailing list
administrator. Another reason that his/her mail address is changed
from @DOMAIN to @SUB.DOMAIN vice versa. Yet another reason is that
he/she replied it from other location which recieved the article via
mail forwarding at some other host.
</para>
<para>
After 2004/10/28 &fml8; current, &fml8; supports "allow article post
irrespective of the From: address if some condition satisfied" at
article_post_restrictions.
</para>
<para>
The current implementation suppors the condition that "if the reply
refers a known message-id within some time limit". Precisely
speaking, "known message-id" implies the id is found at the message-id
database which holds In-Reply-To: and References: of old articles
within some time limit (e.g. one week).
</para>
<sect2>
<title>
Recipes
</title>
<qandaset>
<qandaentry>
<question>
<para>
Article Posting Allowd If It Is A Reply To The Former One.
</para>
</question>
<answer>
<para>
"check_article_thread" is the keyword to enable this check.
<screen>
article_post_restrictions = reject_system_special_accounts
check_article_thread
permit_member_maps
reject
</screen>
Not used by default.
To use it, specify it at article_post_restrictions.
</para>
</answer>
</qandaentry>
</qandaset>
</sect2>
<sect2>
<title>
Discussion
</title>
<para>
Hmm, this is similar to a cookie.
There are some problems.
</para>
<para>
1) What is proper time scale ?
$article_post_article_thread_lifetime controlls it. One day by default.
<screen>
article_post_article_thread_lifetime = 86400
</screen>
</para>
<para>
Also, boundary of the time scale ? When starts the allowd window ? It
starts from the first article of the specific thread ? Or from the
last article ?
</para>
<para>
2) More restricted condition support required ?
If so, we should check the corelation between subject: and the thread?
</para>
</sect2>
<sect2>
<title>
Recipes
</title>
<qandaset>
<qandaentry>
<question>
<para>
Only A Few Persons Can Starts Article Thread.
</para>
</question>
<answer>
<para>
<screen>
member_maps = $tmp_dir/members-thread-init
article_post_restrictions = reject_system_special_accounts
check_article_thread
permit_member_maps
reject
</screen>
Only persons registered at members-thread-init file can post article
always. Other persons can post the article if the article is a reply
to some other article.
</para>
<para>
Hmm, it looks a variation of moderator system ?
</para>
<para>
Better that they use PGP auth if could.
<screen>
member_maps = $tmp_dir/members-thread-init
article_post_restrictions = reject_system_special_accounts
check_article_thread
check_pgp_signature
reject
</screen>
</para>
</answer>
</qandaentry>
</qandaset>
</sect2>
</sect1>
|
