Re: Sophie 3.05 encrypted file issues

Thanks for clarifying that process Scott.

I agree with your point 1 in that it is not the best option to revert 
back to 3.04 behaviour.

As for point 2, I guess there are a couple of routes you could take here.

One option could be to have sophie return a different code other than -1 
and have amavis be aware of this.
Amavis's behaviour could then potentially be controlled by a 
configuration setting that would allow people to either pass the message
or drop the message if it contained a password protected archive.

This would require coordination from both the Sophie team and the Amavis 
team.

Having amavis ignore -1 would also solve this issue, but -1 is also used 
for other critical errors I believe in which case ignoring them could 
introduce new issues.
 From what I have seen of Amavis, the config file contains regex that 
allows it to determine whether a file was virus infected or not, is this 
the case?

If so, if sophie was to return a different code, would it be as simple 
as modifying this regex to pass the different code?

Regards
Jay

[email protected] wrote:

>I just had a look at the amavis code.  It instructs Sophie to scan a
>directory, not a single file.  In past versions of Sophie, scanning a
>directory would ignore errors and always return clean (0) unless a file in
>the directory was infected.  Since amavis scans a directory, it seems it
>was always ignoring error files and silently passing them through.  In
>3.05, sophie_scandir was changed to also report errors, which is what you
>are encountering below.  Scanning a file (sophie_scanfile) has always
>reported errors via the -1 return code.  sophos_scandir was changed so
>that's its behaviour matched that of sophie_scanfile.
>
>So, I guess the options are:
>
>1) Should Sophie be reverted back to 3.04 behaviour to ignore errors when
>scanning a directory?
>I personally think no, since this is rather unsafe
>
>2) Should amavis be changed to handle -1 return codes by Sophie
>differently.  Since amavis only checks the number return code, there is no
>current way to say things like "allow password protected zips but deny
>corrupt files" because Sophie returns -1 in both causes.  I guess you are
>left with the choice of allowing all error files or denying all error
>files.
>Modifying amavis to ignore -1 error codes from Sophie is only a matter of
>commenting out a couple lines.
>
>Any thoughts?
>
>Regards,
>Scott.
>
>
>[email protected] wrote on 12/06/2005 03:02:32 PM:
>
>  
>
>>Hi All,
>>
>>I have just upgraded my mailserver to Sophie 3.05 and
>>libsavi.so.3.2.07.119 using amavisd-new-2.3.1
>>
>>NOTICE           : Sophie configuration file not specified - falling
>>back to defaults
>>NOTICE           : Using Sophie configuration file '/etc/sophie.cfg'
>>NOTICE           : Setting configuration options - please wait...
>>NOTICE           : Configuration options set
>>Sophos engine    : Sophos engine version 2.32
>>Sophie IDE       : Sophos IDE version 4.00 (detects 114935 viruses)
>>SAVI config      : /etc/sophie.savi
>>Max processes    : 20
>>Socket path      : /var/run/sophie
>>Umask            : 7
>>PID file         : /var/run/sophie.pid
>>Timeout          : 300 seconds
>>Running as user  : amavis
>>Socket group     : amavis
>>Logname          : sophie
>>Log facility     : 16 (mail)
>>Log priority     : 5 (notice)
>>Error strings?   : yes
>>Timestamps?      : no
>>Show virus name? : yes
>>Callbacks?       : yes
>>limit_classif    : 10
>>limit_nextfile   : 10000
>>limit_decompr    : 1000
>>socket_check     : yes
>>Sophie version   : 3.05
>>NOTICE           : pSAVI cleaned up and released/terminated
>>
>>
>>When someone sends through an email with a password protected zip file
>>the following is shown in the maillog:
>>
>>Dec  6 04:28:12 xxxxxxxx sophie[32719]: Sophie child has timed-out (no
>>data received in 300 seconds) - process killed
>>Dec  6 04:28:12 xxxxxxxx sophie[1036]: WARNING          : Error: File
>>was encrypted
>>Dec  6 04:28:12 xxxxxxxx amavis[508]: (00508-01) ask_av (Sophie) FAILED
>>- unexpected result: -1:Error: File was encrypted
>>Dec  6 04:28:12 xxxxxxxx amavis[508]: (00508-01) WARN: all primary virus
>>scanners failed, considering backups
>>Dec  6 04:28:12 xxxxxxxx amavis[508]: (00508-01) TROUBLE in check_mail:
>>virus_scan FAILED: virus_scan: ALL VIRUS SCANNERS FAILED:
>>Dec  6 04:28:12 xxxxxxxx amavis[508]: (00508-01) PRESERVING EVIDENCE in
>>/mnt/tmpfs/amavis/amavis-20051206T042306-00508
>>
>>The message is subsequently not delivered and stored in
>>    
>>
>/mnt/tmpfs/amavis/
>  
>
>>This is very much different behaviour than previous versions of Sophie
>>where a password protected zip would not be scanned but would still be
>>delivered.
>>
>>I think it maybe due to this change listed in the Sophie 3.05 changelog:
>>- Bug fix for sophie_scandir problem. Sophie would not report
>>corrupt, password protected, etc files when performing directory
>>scans. It has been changed to return the "worst" result now. If
>>there is an infected file with a scanned directory, the
>>infected return code (1) is returned. If, however, the directory
>>(and all sub-directories) are clean, but there is at least one
>>error (corrupt, password protected, etc) file, Sophie will return
>>the error return code (-1). Only if all files are clean and
>>error free will the OK (0) code be returned.
>>
>>This change appears to indicate that "-1" will be returned when
>>sophie_scandir is called, but according to the output in the maillog it
>>is also being returned when a single file sent from amavis is being
>>scanned and amavis does not know what "-1" means?
>>Is this intentional behaviour, or is this an oversight with this change?
>>
>>I have managed to work around this for the time being by enabling sweep
>>as a fallback scanner in amavis, as sweep does not return an error with
>>password protected zips. This isn't ideal and I was hoping someone here
>>could shed some light on this.
>>
>>Thanks for your time
>>
>>Regards
>>Jay
>>
>>_______________________________________________
>>vtools mailing list
>>[email protected]
>>http://www.vanja.com/list/listinfo.cgi/vtools
>>    
>>
>
>_______________________________________________
>vtools mailing list
>[email protected]
>http://www.vanja.com/list/listinfo.cgi/vtools
>  
>