LSTSRV-L Archives

LISTSERV Site Administrators' Forum

LSTSRV-L

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
"A. M. Mughal" <[log in to unmask]>
Fri, 7 Jan 1994 18:56:29 GMT
text/plain (45 lines)
In article <[log in to unmask]],
Eric Thomas  <[log in to unmask]] wrote:
]On Fri, 7 Jan 1994 08:58:29 EST Nick Laflamme <[log in to unmask]]
]said:
]
]]Or maybe you  want LISTSERV to send  the token and remember  the note so
]]the editor always sends the token back, not the note, but the editor has
]]the note so s/he can discuss it with the original author if needed?
]]
]]1) user sends note to list
]]2) LISTSERV sends note and token to moderator
]]3) moderator echoes token to LISTSERV
]]4) LISTSERV distributes note (which it had kept a copy of)
]
]This would not work because the editor would lose the ability to edit the
]message. One  would really  need the  long procedure. It  is not  easy to
]implement because  the existing token code  is based on the  execution of
]commands, not on resuming the distribution of a message. I can't think of
]any reliable way to  have the editor return a usable  copy of the message
]with the  token (by "reliable"  I mean something  that works with  99% of
]mail interfaces, including  those that don't give the user  access to the
]header). So  the editor would have  to send mail to  the LISTSERV address
]with a confirmation command, rather than  sending the message to the list
]again with (say)  an extra header line containing  the confirmation code.
]This in turn means LISTSERV has to save the message until it is confirmed
]and manage the disk space properly to  avoid abuse. Indeed, it is quite a
]lot of work.
 
        I'm thinking on the same lines as "Subscription= open,confirm" and
        having a similar option for "Send= Editor,confirm". The token system
        I think, is already in place. With 'confirm' option editor will be
        able to return the token to confirm the distribution.  This adds to
        an overhead on the editor and the listserv.
 
        In this case, any forging of Editor's email address will result in
        token sent to the real editor. I'm suggesting, one way to close
        the gap and making it hard for someone to forge messages on 'moderated'
        LISTs. It will be definitely nice if it can be done. There are probably
        other options to reach the same goal.
 
        =Asim
 
]
]  Eric

ATOM RSS1 RSS2