Re: Need clarification of "terminal action" in access_rules

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig28FFE8DA28DD6BBD9F632467
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 10/27/09 04:18, quoth Michael Yount:
> That's why the feature (putting two terminal actions together in an
> access rule) is undocumented.  The "consult" and "deny" actions are
> contradictory.
>=20
> You could forward the messages in a way that allows them to be
> separated.  For example, send them to [email protected]
> and sort them based on the subaddress.
> Even better, you could just use "consult" and have the owner approve or=

> disapprove messages that are thought to contain commands.  If the owner=

> wants to see the message in any case, wouldn't that be simpler?
>=20
> Michael

The problem is that when people send to the list and we *know* that it's
always going to result in a deny, then the use of the deny command gives =
the
poster instant feedback. If we go to using a consult then the amount of t=
ime
between the post and the reject is usually short (< an hour or two) but i=
t
could be as much as a day or more. And if the time lag is that long then =
most
people won't bother to resubmit their message. Bottom line is that when
Josephine Q Public sends a message that gets rejected with instant feedba=
ck
then the frequency that she will resubmit a corrected message is about 10=

times greater. The converse is that when we know what they *tried* to sen=
d,
then we can be proactive in helping them to fix the problem. A lot of peo=
ple
don't even see the bounced message back.

I'm suggesting that there might be a semantic difference between "termina=
l" in
two different access_rules, vs two commands being executed in the same ru=
le.
It might make it a more flexible solution.

IOW,

consult, reason=3D"Unsub found in text"

followed by

deny, replyfile=3DUnsubFoundInText"

is different from

consult, reason=3D"Unsub found in text", deny, replyfile=3DUnsubFoundInTe=
xt

The semantic I'm suggesting would say (in the 2nd instance) that: the ope=
rator
would get a consult token because the consult would not be terminal withi=
n the
rule. (It would be terminal after the rule completes.) The token would ma=
ybe
not even be valid when he looks at it, because the token will have been d=
enied
a nanosecond after the consult was crafted.

Besides the implementation, another table showing what commands are allow=
ed in
the same rule (also possibly specifying an order requirement) would fill =
in
the gap that is already there.

Of course, I'm asking this in the context of having no idea of the comple=
xity
that it might have from your side. :-)

The issue here is very much a case of functionality that is needed becaus=
e the
people who are subscribers are not engineers.

>=20
> Steven W. Orr wrote:
>> Given that forward and deny are both described as terminal in the
>> help, This
>> seems to allow the forward to happen and that the deny works after it.=

>>
>> post
>> [email protected], deny, replyfile=3DUnsubFoundInText=

>> $admin_unsub >=3D 50
>>
>> What does not seem to work is to change the forward to a consult, a la=

>>
>> post
>> consult, reason=3D"Unsub found in text", deny, replyfile=3DUnsubFoundI=
nText
>> $admin_unsub >=3D 50
>>
>> I get no consult from this. Is the doc wrong?
>>
>>  =20


--=20
Time flies like the wind. Fruit flies like a banana. Stranger things have=
  .0.
happened but none stranger than this. Does your driver's license say Orga=
n ..0
Donor?Black holes are where God divided by zero. Listen to me! We are all=
- 000
individuals! What if this weren't a hypothetical question?
steveo at syslang.net


--------------enig28FFE8DA28DD6BBD9F632467
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkrnPXQACgkQRIVy4fC+NySzwgCeJYp8YegxinN2Pt57deqTujc2
fS0AniCgJ4ijKnSa0D/374EVIU0caUIH
=oT4s
-----END PGP SIGNATURE-----

--------------enig28FFE8DA28DD6BBD9F632467--