On Mon, 29 Dec 1997 19:05:14 -0500, Mark Hunnibell <[log in to unmask]> wrote:
>Ben Parker wrote:
>
>> Almost. This will allow editors to post without further approval. To force
>> even editors to approve their own posts, you need Send= Editor,Hold,Confirm.
>
>OK... that's kind of what I want except that I also want to be able to send
>from the editor and over-ride the confirm somehow... with a password or
>something.
This is not presently possible.
>> The confirm mechanism (requiring an exchange of email msgs with the "OK") is the
>> mechanism that ensures reliability of origin.
>
>It seems that I am going to have to get fancy to do something that seems to
>me to be simple. Yes, the OK does a good job of ensuring reliability of
>origin, but it *does* require a human interaction. I was hoping to avoid
>it getting stopped at a human. Here is the application:
>
>A privileged person accesses a special cgi script on our web site. The
>final product of the cgi script is an e-mail sent out something like a news
>release. I want to make the news release go right to the list, but I
>recognize that someone could easily forge the "From:" line to that of the
>Editor and send their own false messages to the list. The Confirm/OK will
>stop that, yes. However, I would like to find a way to override the confirm
>requirement with a password of some kind.
The OK/confirm mechanism does not presently allow for a password bypass. The
limitations you point out are inherent in the mail system as it exists. The
only way to ensure the origin of the msg is to mail to the address in question
and get a suitable response. Yes it is theoretically possible even this could
be 'spoofed' but it is not practical.
>> This is a good description of what a Distribute Job is, however, you have to
>> supply the list of addresses as part of the job, so it's not quite as easy as
>> saying 'send to xxxx-L list'. However, this also requires Postmaster (Site Mgr)
>> privileges and is not usually open to normal list owners.
>
>I am the site manager. This is not a problem. Cannot I just include one
>address (the address of the list) in the DD block?
No. Re-read Chap 11 of the Site Mgr manual about this. You are not actually
using the 'List'. Instead, you are using a supplied address list and LISTSERV's
distribution capabilities, independent of any list that may exist. the 'list'
is not a part of the transaction.
>Even so, will that
>override the Confirm?
Since a list per-se is not involved, the need for a confirm is meaningless in
this context.
>Here's an idea. What if I made the program create some kind of single job
>that temporarily set the Confirm off for the list, distributed the message,
>and then set the Confirm back on. Can I do all that in a sequential job
>somehow?
The only way to 'turn-off' confirm is via a get/put of the (changed) list
header. This could work, but would be cumbersome. It would require 3 separate
jobs, (change the header), (send the distribute job or simply post to the list),
(change the header back), it cannot be done in only one job.
>Thanks
>
>Mark Hunnibell
>[log in to unmask]
--
__________________________________________________________________
Ben Parker ..... L-Soft international Inc. ..... [log in to unmask]
|
