1 Apr 2006 01:06
Re: Pruning e-mail attachments.
Ken D'Ambrosio writes: > Hello, all -- first and foremost, I'm pleased to announce the birth of > Isabella Francesca D'Ambrosio -- for those with places in their hearts > for baby pics, have at: http://flyingtoasters.net/gallery/album26?page=4 > . Now that the birth done with, I hope to be able to make impending > meetings again (what with all my new-found spare time </sarcasm>). [congratulations email sent seperately(Continue reading)] > And now for the actual on-topic stuff: I've got a Blackberry user who > gets inbound e-mail bounced from time to time because of large > attachments. Since I route all his e-mail both to his IMAP account and > the Blackberry, there's no reason I couldn't strip off the attachments > -- *IF* I knew what it was that designated the start of an attachment. > Upon looking at the raw text of a message, I remain somewhat ignorant. > While I'm somewhat tempted to delve into the RFC's, if there's a > quick-n-dirty way to find out where to start stripping off text, I'd > appreciate being told about it. Download the Perl MIME::Tools library. Look in the examples directory. There's a little program here called "mimeexplode". Run the specified email through mimeexplode. If any of the attachments that are dumped out are >N, where N is the max size of messages that don't get bounced, then cobble together a new message from the smaller attachments and send this instead, adding a note to
> >
> > 1 << (32 - n) in binary is (n-1) '0' bits, a '1', then (32 - n) '0'
> > bits. Subtracting 1 from that gives n '0' bits followed by (32 - n) '1'
> > bits. The 'not' operator flips all the bits for the netmask.
> >
> > This works for /1 through /32 networks, even though some of those are
> > nonsensical. A /0 might break this because of overflow (1 << (32 -n)
> > overflows a 32-bit integer); theoretically, it should work even for /0
> > so long as 1 << (32-n) returns 0 (32-bit gcc 4.0 on my Athlon64 desktop
> > computes this correctly, but complains 'warning: left shift count >=
> > width of type' while compiling. Anyway, if you're running a /0, you've
> > got other, bigger problems.
>
> Using gcc 3.4.4 on a 32-bit Pentium III, I get no warnings when
> compiling your test program, even with -Wall. When it runs, 0 gives the
> same result as 32, so it overflows (silently) on my machine.
Ooh, here's something interesting. I first tried a test with constants,
and got the warning: left shift count >= width of type" out of gcc.
Then I rewrote the thing to use a loop, and I got correct results out of
it. (This is all on an Athlon64X2.)
TIA
RSS Feed