a while back the suggested way to go with this seemed to be to save the
pdf, scan it for viruses, if the scan comes up clean then leave the
orriginal pdf in place, if not then do something else with the pdf. I
was looking into doing this and writing a bit of a description on how to
do it but it kind of fell by the wayside and I've got too many things to
do to pick it up now. If you think this might be the way to solve your
problem, have a look back through the archives, below is a quote out of
one of the mail messages that sums up what the idea is.
From an email around May 2003 on the Anomy List:
> > >
> > > Currently the only way to avoid this problem is to wrap the
> > > sanitizer in a procmail ruleset or helper script which will
> > > quarantine the original unmodified message and use it verbatim if
> > > the sanitizer doesn't find any security risks in it.
> > I could do that, as I always write incomming message to disk before
> > sending to sanitizer, then amavis adn another script for loging
> > attachment in DB.
> > But how could I know if sanitizer hit something or no, I desn't see a
> > particular exitcode using $?
> I didn't see the score_bad option and the "!" possible on the policy to
> increment the score. I now use this to get an exitcode != 0 and got a
> new working script which send the original message if the exit code is
> It just needs a little bit more disk io ;-// but it works.
If you do get something to work, then I'm sure others would appreciate
if you can post a description so that we all don't have to work it out
step by step.
Dustin Puryear wrote:
> Precisely. Because binary files, i.e., a PDF, is being encoded using QP
> encoding Anomy is garbling them. (Not that Anomy is buggy. It's the mail
> clients that are buggy.) If you hit the Anomy archives you will understand
> the problem.
> The actual plan right now is to either undo the changes made by Anomy, or to
> simply stop Anomy from making the changes in the first place. I'm simply
> hoping someone has already modified and tested these changes in Anomy.
> ----- Original Message -----
> From: "Marvin Herbold" <email@example.com>
> To: "Dustin Puryear" <firstname.lastname@example.org>
> Cc: <email@example.com>
> Sent: Monday, November 10, 2003 7:52 PM
> Subject: Re: [anomy-list]: The QP encoding issue - again!
>>Umm - aren't PDF files binary? Simply converting LF to CRLF would
>>royally screw up these files... like in places where there is supposed
>>to be a 0x0A byte without a preceeding 0x0D byte.
>>Dustin Puryear wrote:
>>>I'm glad you mentioned that. That is actually the plan of attack that we
>>>decided on, but for some reason I didn't list it. If someone has already
>>>done this then let us know. I would hate to reproduce the effort. Thanks!
>>>Reports suggest that this happens mostly with some graphics files and
>>>Anyone have experience with this on other files?