Hello all, remember me? Yes, I'm still cranking along and I'm pretty
pleased with what works so far. I wrote some more documentation and did a
whole bunch of testing. The whole request->token->accept thing is working
out very well; I think owner approval for who and which requests will go a
long way towards eliminating many of the worries those requests present for
security-conscious list and site owners. (The fact that users can choose
to hide their address or their name and address from who requests will
help, too.)
The big news is that Eryq is back in the game and has sent me a prerelease
copy of the new MIME-Tools 4 to work with. He's added essentially
everything I needed (though I keep coming up with more) including handling
of some nonstandard encodings like x-gzip and x-uuencode. Also, as a
bonus, the preamble and epilogue of multipart messages are kept and can be
changed. This is very nice. Unfortunately I can't now snapshot until he
releases it (because nobody except he and I could run it), but I don't
think it will be too long.
Now that I have the MIME handling I need, I get to work on resend some
more. First up (for this weekend) is message approval. MIME makes this
hugely complex. Here are some possibilities I'd like to support, but I'd
like comments. (I intend to use only the token stuff and bypass the
old-style stuff altogether for my lists, but you need the other things if
you want to edit messages).
Approval types (i.e. the message doesn't bounce at all)
------------------
token
When a message bounces it generates a token. The owner accepts the token
and the message is approved.
header
The good old Approve: header. If it's there and the password is valid,
the message is approved.
attachment
If first part just has the line Approve: password token and the other
part is of type message/rfc822, the message is extracted and sent. (This
means that well-behaved mailers be able to just forward the message,
adding the Approve: line.)
post command
You can send a command like: approve password post list <<END and include
an entire message afterwards. Or you can attach the message and do
approve password post list <@. Of you can stuff the message in a file
and use the shell interface. Whee.
body
Approve: in the body, possibly followed by headers. If no headers,
remove the approve line and use the headers of the message. If headers,
reparse starting from the next line. (This is 1.94.x behavior, and is
painful to deal with.)
If the Approve: line looks like Approve: password token, the token is
removed from the list and acknowledged as being approved. Otherwise the
token that was generated when the message bounces will have to time out.
But what does "body" mean? If we have a multipart message, where do we
look? The body of the first part? In the preamble? Somewhere else? It
starts to get complicated, and I can't keep track of all of the
implications.
- J<
Follow-Ups:
|
|
