Before I get into this, I'll just say that a lot of the stuff proposed for
attachment_rules is just wishful thinking and isn't going anywhere unless
someone finds a whole bunch of time to work on it. To me the only really
important thing is a way of consulting the list owner if the message
contains parts that aren't wanted, and even that is going to come much
later.
>>>>> "BLH" == Brian L Heess <dmbong@commline.com> writes:
BLH> Yeah, I'd like to see a list of broken mailers and MTA's.
I think these days everything is broken to some extent. It depends on how
you define broken. I mean, there isn't a standard for mail readers. MTAs
are a different breed, but I'm sure we'll have to eventually worry all
about them because Majordomo 2 talks a whole lot of SMTP.
BLH> The attachment storage section looks kinda cool, but also could be a
BLH> NASTY bear to manage, letting people realize they can do it and doing
BLH> all kinds of nasty things to your system.
Well, I don't think its any worse than the situation without it. The
messages will already get in the archives and will have the possibility of
stuffing up your mail queue, so stripping off a piece and storing it
elsewhere really makes no difference.
BLH> I suppose we should list every darned known type in there, since
BLH> places like Microslop seem to add new ones all of the time, and the
BLH> application/ types don't usually seem to cut it. :)
Well, we've talked about the possibility of using regexps (although there's
also some desire to have a simplified regexp syntax that is really off
topic for this message). And since the first matching rule gets it, you
just insert catch-all "drop 'em" rules at the end. "application/.*
DISCARD" makes my day.
BLH> a size rule might somehow be introduced..or the pass=8bit result
BLH> should be included in the size of the resulting message which then
BLH> gets checked by the normal bounce message.
I wonder if it isn't just better to have a maximum message size and a
maximum part size and not make it content dependent. After all, why allow
big images but not large text files? (Plus it makes things simpler, and at
some point simpler does equate to better. Unfortunately I think I've
already tossed too much simplicity, but I do like what it bought me.)
BLH> Also, the results of the detach type might want some name rules for
BLH> them, like if they go into an "archive" type dir, they get a code
BLH> stuck in front of them so they end up in date order and somehow become
BLH> recognizeable to people as belonging to a message they have read, or
BLH> finding the file then have an idea of how to find the message that it
BLH> went with.
The whole idea behind detached bodies is that they're spooled and get
junked after a while. It's purely a bandwidth saver and not an archival
method. The MIME standards help us here, because they allow nice things
like expiring detached bodies. My guess is that there probably aren't any
mailers that actually support is, though.
BLH> Also, in the output of the message it came from, it'd be cool to
BLH> include a reference to where the detached file went, ie:
I think that was already in there.
BLH> These and the above I would assume would be list specific or at least
BLH> COULD be.
Probably, because you grab them with a get command and that takes a list.
BLH> Yeah, and I'd say that it might be relative to what type the file was,
BLH> too...so, yet another configurable thing in the "rules"
The idea is they are assigned meaningless numbers. Remember, they're just
tempfiles; pretend that the name is just a spooled token which gives you
back a file and which expires in a few days.
BLH> I opt for ANOTHER also...one that returns the message to the submitter
BLH> as garbage. :) (with a note saying to read any rules) [this would be
BLH> noted in the config file saying that it's NASTY to return a message to
BLH> somebody if there was never anything telling them not to submit such
BLH> things prior to this...
Well, we have the "deny" action for requests which sends back anything you
want. It should probably end up in these rules eventually.
>> 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.
BLH> THIS ROCKS!
This is really the whole point of attachment_rules. Well, this and REJECT
or DENY or something. Everything else (especially detached bodies but
also re-encoding) is pie-in-the-sky stuff that will happen only if someone
finds a pile of free time. I think I'll go back to the top and make that
clear.
BLH> Bounce might be looked at... Bounce to me sounds like RTS (return to
BLH> sender).
I universally use CONSULT for something that asks the list owner for
approval and CONFIRM for something that asks the victim (person who is
effected) for approval. So I'd call it CONSULT. The access_rules already
use consult, confirm, deny, allow, confirm+consult (asks both the victim
and the owner) and forward (passes the request on to another Majordomo
server running on another machine) plus reply, replyfile and mailfile (for
communicating what happened back to the requester). I'll borrow what works
from these to make attachment_rules.
Now, I have a pretty good idea how I plan to implement all of this, so I
should at least put some skeleton code into Resend.pm in case anyone wants
to play with it themselves.
- J<
References:
|
|
