Re: Question about how to run a deny in access_rules.

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

On 10/13/09 18:01, quoth Michael Yount:
> If the "ackdeny" flag is set for the author, and the
> "ack_attach_original" setting is configured appropriately, the posted
> message will be attached to the denial acknowledgment.
>=20
> There is no way to attach the posted message to the "inform" notice, bu=
t
> you could use the forward action in the access rule, e.g.,
>  [email protected], deny, replyfile=3Dmyfilename
> to forward the message to the owner separately.
>=20
> (Test these suggestions to make sure they work as you expect.)
>=20
> Michael
>=20
> Steven W. Orr wrote:
>> On 10/04/09 00:50, quoth Steven W. Orr:
>> =20
>>> On 09/30/09 22:42, quoth Michael Yount:
>>>   =20
>>>> Use a rule in the inform configuration setting, e.g.,
>>>>  post | fail | inform
>>>>
>>>> Michael
>>>>
>>>> Steven W. Orr wrote:
>>>>     =20
>>>>> I have a few situations in my lists when I want the person to be
>>>>> automatically
>>>>> denied, but I would also like to be informed on when it happens.
>>>>> Currently, I
>>>>> see no way to do this.
>>>>>
>>>>> For example, I currently have a number of these constructs in my
>>>>> access_rules:
>>>>>
>>>>> post
>>>>> deny, replyfile=3DMultiTo2
>>>>> $admin_bothlist2 >=3D 2
>>>>>
>>>>> The person who sends the message is getting the rejection, but is
>>>>> there some
>>>>> way that I as the list owner can get a copy when this happens?
>>>>>
>>>>> Thanks.
>>>>>
>>>>>          =20
>>> Ok. One more followup. I'm getting the inform that I wanted but I'd
>>> also like
>>> to both see the reply contain the content that caused the deny and
>>> for the
>>> poster to also see it.
>>>
>>> Doable?
>>>
>>>
>>>    =20
>>
>>
>> Sorry to be a pain, but this is a piece of functionality that I really=

>> need.
>> Is there anything that I can do, or even a trick, a hack, a tweak,
>> anything,
>> that will cause the replyfile to contain the text that was sent? I
>> reallly
>> need to see both the headers and the content. The post | fail| inform
>> got me
>> halfway there.
>>

I tried it and I'm thinking I might be finding a bug. I have a test list =
with
two subscribers. The dummy's name is auto. Auto has noackstall but he doe=
s
have ackdeny.

Majordomo>show [email protected]

  Address: [email protected]
    Address is valid.
      Address Mailbox: [email protected]
    Registered as            [email protected]
    Registered on            Fri Jun 19 23:02:44 2009
    Data last changed on     Fri Jun 19 23:02:44 2009
    Subscribed to            1 lists

      mjtest:
        Subscribed as   [email protected]
        Subscribed on   Fri Jun 19 23:02:44 2009
        Last changed on Tue Oct 13 23:42:51 2009
        Receiving       each unduplicated message
        Subscriber flags:
          noeliminatecc
          nohide
          nohidepost
          nopostblock
          prefix
          replyto
          selfcopy
          norewritefrom
          noackstall
          ackdeny
          noackpost
          noackreject

Also:

configset mjtest ack_attach_original <<ENDAFR
fail
stall
ENDAFR

configset mjtest inform <<ENDABX
post | fail | inform
ENDABX


According to the ack_attach_original docs, this should cause the original=
 to
be attached to the replyfile message sent to the poster as a result of th=
e
deny, replyfile=3D
It does not. Is this not a bug?

Then I tried this as suggested in the access_rules:

post
forward, deny, replyfile=3DUnsubFoundInText
$admin_unsub >=3D 50

This sort of works, but it turns out it's really not useful. The list-own=
er
gets the forwarded copy but literally has no way to tell if it came from =
the
list or if it's the result of the forward; The From: line says who sent i=
t and
the To: line says the list name, instead of the saying To: list-owner.

Yes, the poster gets his replyfile, and, if I set inform
post | fail | inform
then I as the list-owner will get a message but it does not have the atta=
ched
original.


So here's what I'm proposing (and of course, presuming on your time).

1. Fix ack_attach_original so it does what it's advertised to do.

[[The ack_attach_original setting determines whether an acknowledgement
message will include (as a MIME attachment) the original posted message.
Acknowledgement messages are sent to give the authors of posted messages
details about the progress of their posts.  Whether or not an
acknowledgement message is sent depends upon the ackdeny, ackpost,
ackreject, and ackstall flags for the person who posted the message.]]

2. Fix the help text for configset_access_rules. It says:

The following table summarizes every action that can be used on
the second line of an access rule.  The first rule that matches the
command and conditions and that contains a "terminal" action will cause
all succeeding rules to be ignored.


Instead, it would be clearer to add something like:

Multiple actions may be used on the second line of an access rule. If mul=
tiple
actions on the same rule are terminal actions, they will all still be exe=
cuted.

Also, is this correct?

deny             yes     repl_deny or ack_denial
forward          yes     repl_forward

I'm not seeing the syntax to specify the repl_forward and the repl_deny i=
n the
same line as this:

forward, deny, replyfile=3DUnsubFoundInText
unless this is legal syntax

[email protected], replyfile=3Dheres_what_is_forwarded, deny,
replyfile=3DUnsubFoundInText

3. Would it be a big deal to add syntax so we could say
configset listname inform <<ABC
post | fail | inform_attach
ABC

This would solve my problem because the body already contains the replyfi=
le I
want and the attachment would tell me what he sent that got denied.

Does this make sense?

--=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


--------------enigF98469B1CE218A9B79073B65
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/

iEYEARECAAYFAkrVWNMACgkQRIVy4fC+NyT8HQCfZMmPgmNuSDp0BI6ZoPuAn0Vw
DRIAnAyKABNuxexMarcHrag1gcf3x5lY
=J6jJ
-----END PGP SIGNATURE-----

--------------enigF98469B1CE218A9B79073B65--