On Wed, 12 Aug 1998, era eriksson wrote:
On Tue, 11 Aug 1998 09:36:18 -0700 (PDT), Joe Pruett <joey(_at_)q7(_dot_)com>
wrote:
> i looked at various versions of solutions to this problem and found them
> all too complicated. so i wrote the following /etc/procmailrc file. the
> basic theory is to just rewrite the mime headers to be disabled whenever
> something fishy comes through. i defined fishy to be 80 chars or more in
> any mime header or any wrapped mime header in the body of the message (to
> avoid trying to figure out the length of a wrapped line). am i missing
> any other cases that people have seen?
What you're doing is dangerous, IMHO. It can and will wreak havoc on
quite legitimate MIME messages.
so far it hasn't affected things adversely. this is for a small private
network and they were willing to cope with that possibility. i'll tweak
the rules if needed.
> DROPPRIVS=yes
> :0fw
> * HB ?? 9876543210^0
>
^Content-[^:]*:................................................................................
> * B ?? 9876543210^0 ^Content-[^:]*:[ ]*\/.*(^[ ].*)+
> | /bin/sed 's/^Content-/X-Content-/'
In the absence of Content-Xxx but in the presence of Mime-Version: 1.0,
the MIME spec says the contents are unambiguously 7-bit us-ascii. This
might not be on par with reality.
Content-Description can and will reasonably contain longish strings
without being a threat of any sort (to any reasonable MIME client).
i'm not convinced that a reasonable mime client exists :-). i didn't want
to try to figure out which kinds of headers could cause problems. this
bug should be fixed within a few weeks, at which point the procmail
filters will be removed again.
I'm not sure I get the matching against the body. Why do you grab
stuff into MATCH, and shouldn't the first character after \/ be a
non-blank? Perhaps the intent was really to have the same sort of
condition as on the first line? (And, aren't you risking grabbing
something bigger than LINEBUF, in which case you can get Procmail to
crash if and when you use $MATCH?)
oops, that is leftover from my initial experiments of trying to capture
the info into MATCH and checking the length of that, but that method just
don't work unless you explicitly look for each kind of header (which i
wasn't sure i could enumerate). the second line is just looking for
continued content headers in the body (since procmail doesn't
automatically concatenate them there), but it was being greedy. here's my
newer simplified form:
DROPPRIVS=yes
:0fw
* HB ?? 9876543210^0
^Content-[^:]*:................................................................................
* B ?? 9876543210^0 ^Content-[^:]*:.*(^[ ].*)
| /bin/sed 's/^Content-/X-Content-/'
If you do decide to go with this, perhaps the sed clause should be a
bit more restricted, so as not to gratuitously change stuff like
Content-based filtering is not problem-free <-- at the beginning of a line
the sed is only going to be run when the message looks fishy, so it can be
a little overzealous.
Personally, I liked the earlier solutions better. If there is a
problem, fix it, otherwise don't muck with people's mail. (A real
MIME-capable filter program is probably the best thing to use, but
Procmail is a good vehicle for determining when it's needed.)
i wasn't convinced that all the attempts to fix things would actually
work. and as i said above, this is for a small private network so the
risks were acceptable to them.