This document is under development as a testing protocol for ezmlm-idx
functions. It is made for program development and testing. While normally
the documented behavior has been verified by testing before a release, this
is not guaranteed. In fact, there is no warranty whatsoever. However, all
code is in plain view, so you can do your own testing, verification, etc. You
may even find this document useful for that purpose.
If you're curious or if ezmlm-idx doesn't do what you expect,
you may find more info here. Please report any discrepancies to the authors.
Prerequisites: 5 E-mail addresses:
- Arthur: moderator
- Art: receives mail forwarded from Arthur.
- Bert: moderator (receives requests, but never does anything)
- User: normal user (tries to (un)sub user & joe)
- Joe: normal user
To generate a bad cookie, substitute 1 character in a good one.
To generate a fake -vc/-tc, make it from a -sc/-uc. This should give a new
-vc/-tc only to moderators, NEVER to users.
In all cases, please check that:
- The message starts with "Hi, this is the "
- The message is appropriate.
- The message contains info on commands (DIR/bottom) and the trigger OR
DIR/mod-sub and no trigger.
A message is always sent as a result of a request/trigger.
When sent to more than one address, the addresses are stated explicitly.
"trigger" means copy of the triggering message, i.e. the previous message
in the exchange. Users should notr receive these from moderator-initiated
requests, provided that the list is set up to recognize the request as a
moderator one (i.e. DIR/remote). If not, a moderator request is treated as
if it came from a user.
A fatal error always returns the offending message (trigger).
When a moderator replies to a CONFIRM request, the target is notified only
is the subscriber status of the target changed (non-subscriber -> subscriber,
or vice versa), but not otherwise.
|
