On 19 Dec 1997, Jason L Tibbitts III wrote:
> Well, I don't mind people attaching patches and such. It does bother me
> when done uselessly (like to include a stupid redundant text/html part)
> but anyone without the benefit of a MIME-capable mailer is pretty much
> in the stone age these days.
Yes, but pine is a bear to make handle somethings like HTML, which really
bothers me. Then the abundance of new users on the net using Netscape and
MSMail...
> Sounds like you're a prime candidate to plug for input/work on the
> MIME-munging scheme that was put forth a while back. I'll include it
> below. (NOT as an attachment; after all, it's just text.)
Hmmm..yeah, I remember that now. I can definitely have input...at this
point I barely have time for my own work (ha ha) let alone my girlfriend
these days (actually, my lists and websites have suffered greatly lately
:)
> What do you mean by forgetting the rest? If you mean not checking the
> other parts, then I completely agree. Preamble, first part, or nothing.
Yep, you got it!
> that follows. Sounds complex but it's not too bad. (I'd prefer to use
> parse_nested_messages, but that requires that the enclosing message
> specify content-type: message/rfc822 and I can't rely on that.
Yeah, and these days (Eudora 4 is now 20MB to d/l) you can really only
seem to rely on the fact that things will become really messy...maybe new
"standards" are appearing, but, the software these days is now
implimenting EVERYTHING that can make their product "better" than the
other guy's...
> Supporting broken mailers and weird approval methods that go along with
> them is going to be the most painful thing.
Yeah, I'd like to see a list of broken mailers and MTA's. Having a list
somewhere might make the authors/companies fix the stuff. I hate the PMDF
messages that I get, along with some of the exim and other ones that have
let people customize the error messages into complete uselessness.
> MIME-munging scheme follows; see it also as the file MIME-munging in any
> recent snapshot.
Excellent. Thanks.
The attachment storage section looks kinda cool, but also could be a NASTY
bear to manage, letting people realize they can do it and doing all kinds
of nasty things to your system. I see you have the "what to do with this
type" in there...that'll help. I suppose we should list every darned
known type in there, since places like Microslop seem to add new ones all
of the time, and the application/ types don't usually seem to cut it. :)
> attachment_rules << END
> multipart/mixed bounce
> application/ms-tnef discard
> application/* detach=decode
> text/* pass=8bit
> END
a size rule might somehow be introduced..or the pass=8bit result should be
included in the size of the resulting message which then gets checked by
the normal bounce message.
Also, the results of the detach type might want some name rules for them,
like if they go into an "archive" type dir, they get a code stuck in front
of them so they end up in date order and somehow become recognizeable to
people as belonging to a message they have read, or finding the file then
have an idea of how to find the message that it went with. WOW, a new
idea for file submissions to an archiving place!!!! :)
Also, in the output of the message it came from, it'd be cool to include a
reference to where the detached file went, ie:
Attachment saved:
ftp://ftp.commline.com/pub/Lists/GLU/attach/19971219-Intro.ram
or something along those lines...could be ugly, but...could also be
helpful.
> attachment_dir = "/some/path"
> attachment_url = "http://host/some/path";
These and the above I would assume would be list specific or at least
COULD be.
> o $attachment_url does not have to be set (non-Web-enabled sites).
Yeah, and I'd say that it might be relative to what type the file was,
too...so, yet another configurable thing in the "rules"
> o The BOUNCE action means presence of the MIME type causes the entire
> message to be sent to the list-owner for approval.
I opt for ANOTHER also...one that returns the message to the submitter as
garbage. :) (with a note saying to read any rules) [this would be noted
in the config file saying that it's NASTY to return a message to somebody
if there was never anything telling them not to submit such things prior
to this...
> o The DISCARD action means the attachment will be removed from the message,
> neither archived nor passed on. The rest of the message will continue to be
> processed.
THIS ROCKS!
> o The DETACH action means the file will be stripped from the message and
> saved to the $attachment_dir directory. A snippet about how to retrieve the
> file via email will be inserted into the message:
> +---------------------------------------------
> | To retrieve this attachment, send mail to
> | $list-request@$whereami with the command
> | GET $list $filename
> +---------------------------------------------
> If $attachment_url is specified, the message will also contain
> Web-retrieval instructions:
> +---------------------------------------------
> | To retrieve this attachment, send mail to
> | $list-request@$whereami with the command
> | GET $list $filename
> | or via the URL
> | http://host/some/path/$filename
> +---------------------------------------------
As I said above, these are good, but of course I go for as tiny as
possible, I suppose that'd be much like the footer/header stuff in 1.x
versions, let the manager say how it's done.
> The biggest problem I am having is that I come from a UUencoded non-MIME
> world. I tried to incorporate some of the MIME and translation stuff that
> Jason had talked about, but I am really clueless in that area. This needs
> work. But ask me to propose the non-MIME side and I'll feel comfortable
> with it.
Excellent work Bill! I love it.
> What else needs work?
We can figure that out as is goes.
> Are there better "action" names?
Bounce might be looked at... Bounce to me sounds like RTS (return to
sender).
> Are there any other actions that you think will be necessary?
I thought of some but forgot as I spewed the above out.
> How should we handle no attachment_rules defined (automatically BOUNCED or
> PASSED)?
Do what Majordomo does now, wait...I even forget that since I've changed
so many things...I guess the main thing that I notice is that attachments
often trigger size rules.
This would probably become apparent as it starts to exist (the defaults to
put in the config.
If I didn't say anything about what Bill wrote (as the "o" items) it
likely means I thought it was good.
Cheers!
-Brian
whew, I am going on vacation on tuesday, so I guess I had to type a lot to
make up for the no typing I hope to be doing.. :)
Follow-Ups:
References:
|
|
