On Wed, 12 Aug 1998 09:22:24 -0700 (PDT), Joe Pruett <joey(_at_)q7(_dot_)com>
wrote:
On Wed, 12 Aug 1998, era eriksson wrote:
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.
I'm not sure if this was clear enough. What I'm trying to say is that
if you clobber the Content-Xxx by changing them to X-Content-Xxx, you
could end up producing messages which look to a client like they're
supposed to contain safe 7-bit short lines, when in fact the
information you clobbered would indicate otherwise. The client could
then go on to make assumptions about how to display what might be
binary porridge with horribly long lines in it, crashing and burning
left and right.
I would probably prefer to have the messages disarmed in some other
fashion, perhaps by embedding them in another layer of MIME -- I'm not
sure if this is a good idea in your circumstances, but if it forces
people to check what it is they're opening, it could be all you need.
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).
Content-(Anything) is a pretty good guess. Again, RFC2045 has the
details.
the second line is just looking for continued content headers in
the body (since procmail doesn't automatically concatenate them
there),
A continued header line is not necessarily long, and conversely, a
long header line is not necessarily wrapped.
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.
But it's simple to fix. How's this:
DROPPRIVS=yes
Char="($[ ]|.)" # newline followed by blank, or any other character
Four="$Char$Char$Char$Char"
Twenty="$Four$Four$Four$Four$Four"
:0fwHB
* $ ^Content-[^:]*:$Twenty$Twenty$Twenty$Twenty
| sed -e 's/^Content-[^:]:/X-&/' -e 's/^Mime-Version:/X-&/'
# or, a pipeline to make a message/rfc822 with a suitable Subject:
The condition expression actually allows for slighly longer matches
than eighty characters, in the case where headers are wrapped (one
extra char for each wrapped line). Wasn't the dangerous limit actually
lower than 80 characters (63 sounds like a familiar number)?
As a reasonable compromise, again, the sed script could be replaced
with a Perl one which would include Mail::MIME and really only Do The
Right Thing.
i wasn't convinced that all the attempts to fix things would actually
work.
What exactly did you find wrong with them, other than that they looked
"too complicated" (quoting from memory here; sorry if I misquote you)?
Don't get me wrong: I'm not saying your solution is broken beyond
repair or anything, just that I'd do it differently (and speculating a
bit about how I might do it).
/* era */
--
Bot Bait: It shouldn't even matter whether (`') Just (`') http://www.iki
I am a resident of the State of Washington \/ Married! \/ .fi/~era/