headers
Gustavo Castro | 8 Feb 2011 19:44
Picon

Re: Problem with attach

Hi,

  Well, I've continued my research on this matter and found something
interesting. Long story short: somehow, when ripmime is executed over
this email containing a single word file, it extracts a zero length
file named just "d". Then, when the function str_rstr() compares the
file name with the extensions provided in the simcontrol file (inside
check_attach()), it returns -1 when the last character of the
extension tested matches the only character in this filename. The bad
extension "found" was ".cmd", so this last "d" is equal to the
filename of the supposedly attached file generated by ripmime, so
simscan returns exit code 82 and game over.
  The solution should be to fix ripmime, as it's extracting a
non-existent zero length file (adding endless fun to my otherwise
boring week), but as I was trying to get this to work asap (so no more
flaming arrows hit my door), I've wrote a small workaround in
simscan.c so it ignores the file when its name length is shorter than
the extension to check at that time. That way, I rest assured that the
extension will be checked more properly (from my point of view), and
it's faster for me than to debug ripmime... (BTW: I'm using ripmime
1.4.0.9). I know it's not clean and may not be the best way to deal
with the problem, but it worked for me and I really, really need to
sleep well tonight...
  My quick 'n dirty "fix":

------------------------------------------------8<-----------------------------------------------------
--- simscan-1.4.0/simscan.c 2011-02-08 16:00:43.579074836 -0200
+++ simscan-1.4.0-fixed/simscan.c 2011-02-08 16:04:24.931075207 -0200
 <at>  <at>  -1735,10 +1735,14  <at>  <at> 
     for(i=0;i<MaxAttach;++i) {
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gustavo Castro | 9 Feb 2011 15:28
Picon

Re: Problem with attach (slight correction)

Hi,

  Where I've wrote "it returns -1", I should have wrote "it returns
0". Now that I'm fully awake, I've read it again and realize of the
error... That's it. Thanks!

Cheers,
  Gustavo

2011/2/8 Gustavo Castro <gcastrop@...>:
> Hi,
>
>  Well, I've continued my research on this matter and found something
> interesting. Long story short: somehow, when ripmime is executed over
> this email containing a single word file, it extracts a zero length
> file named just "d". Then, when the function str_rstr() compares the
> file name with the extensions provided in the simcontrol file (inside
> check_attach()), it returns -1 when the last character of the
> extension tested matches the only character in this filename. The bad
> extension "found" was ".cmd", so this last "d" is equal to the
> filename of the supposedly attached file generated by ripmime, so
> simscan returns exit code 82 and game over.
>  The solution should be to fix ripmime, as it's extracting a
> non-existent zero length file (adding endless fun to my otherwise
> boring week), but as I was trying to get this to work asap (so no more
> flaming arrows hit my door), I've wrote a small workaround in
> simscan.c so it ignores the file when its name length is shorter than
> the extension to check at that time. That way, I rest assured that the
> extension will be checked more properly (from my point of view), and
> it's faster for me than to debug ripmime... (BTW: I'm using ripmime
(Continue reading)

Permalink | Reply | 2 comments |
headers
Matt Brookings | 10 Feb 2011 16:41
Favicon

Re: Re: Problem with attach (slight correction)


On 02/09/2011 08:28 AM, Gustavo Castro wrote:
>> flaming arrows hit my door), I've wrote a small workaround in
>> simscan.c so it ignores the file when its name length is shorter than
>> the extension to check at that time. That way, I rest assured that the
>> extension will be checked more properly (from my point of view), and
>> it's faster for me than to debug ripmime... (BTW: I'm using ripmime
>> 1.4.0.9). I know it's not clean and may not be the best way to deal
>> with the problem, but it worked for me and I really, really need to
>> sleep well tonight...

It sounds like not only is there a bug in ripmime, there's also a
slight bug in simscan's handling of filenames.  I'll look into this.
--

-- 
/*
    Matt Brookings <matt@...>       GnuPG Key FAE0672C
    Software developer                     Systems technician
    Inter7 Internet Technologies, Inc.     (815)776-9465
*/
Permalink | Reply | 0 comments |
headers
Tom Collins | 11 Feb 2011 01:26
Gravatar

Re: Re: Problem with attach (slight correction)

Here's how I fixed it, some time ago -- the return statement ensures that all characters in n are at the end of
h, and you don't need the other changes Gustavo made.

int str_rstr(register char *h,register char *n)
{
 register char *sh;
 register char *sn;

  for(sh=h;*h!=0;++h); --h;
  for(sn=n;*n!=0;++n); --n;

  for(;h>=sh && n>=sn;--h,--n) {
    if ( *h!=*n ) {
      return(-1);
    }
  }
  return((n < sn) ? 0 : -1);
}

This was included in my patch on SF:
http://sourceforge.net/tracker/index.php?func=detail&aid=1829073&group_id=204569&atid=990138

This issue came up way back in April 2007, it's a shame it was never fixed in a release:

On Apr 24, 2007, at 8:57 AM, Ken Jones wrote:
> Not sure what we can do about this if ripmime isn't decoding
> the mime attachments correctly.
> 
> Perhaps we should think about switching to the EPS library and
> rip the attachments out with the EPS library calls.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nickitas | 11 Feb 2011 11:36
Picon

Multiple recipients and spamassassin

Hi ,

  We are using simscan for quite a while without any problems . The only 
problem we have is spam checking when a e-mail have multiple recipients 
. I know simscan was designed that way , but I was wondering if a patch 
has been written to deal with this kind of situation . It would be nice 
if e-mails were rejected instead of accepted and bounced .

Thank you in advance :)

!DSPAM:4d55119c32712933690810!
Permalink | Reply | 2 comments |
headers
Hugo Monteiro | 11 Feb 2011 12:08
Picon
Favicon
Gravatar

Re: Multiple recipients and spamassassin

On 02/11/2011 10:36 AM, Nickitas wrote:
> Hi ,
>
> We are using simscan for quite a while without any problems . The only 
> problem we have is spam checking when a e-mail have multiple 
> recipients . I know simscan was designed that way , but I was 
> wondering if a patch has been written to deal with this kind of 
> situation . It would be nice if e-mails were rejected instead of 
> accepted and bounced .
>
> Thank you in advance :)
>
>
> 
>
>

In order to apply spam rules on a per user basis, you will need to 
demultiplex the message before feeding it to simscan. Usually you can 
accomplish that by setting a second mta instance where you run the 
content analyzer. Usually i only run anti-virus at the first smtpd 
instance and the content analyzer either on a second instance or at 
delivery time (where message was already demultiplexed).

Regards,

Hugo Monteiro.

--

-- 
fct.unl.pt:~# cat .signature
(Continue reading)

Permalink | Reply | 1 comment |
headers
Nickitas | 11 Feb 2011 13:24
Picon

Re: Multiple recipients and spamassassin

Hi ,

  This is a nice solution but it will not solve the bounce problem . I 
can of course write a wrapper around qmail-remote to silently
reject bounces but I am trying to find the best solution that would 
satisfy everybody ( senders , recipients , customers , RBLs ) ...

Thank Hugo (and btw I know realized your repos are up) :)

On 02/11/2011 01:08 PM, Hugo Monteiro wrote:
> On 02/11/2011 10:36 AM, Nickitas wrote:
>> Hi ,
>>
>> We are using simscan for quite a while without any problems . The 
>> only problem we have is spam checking when a e-mail have multiple 
>> recipients . I know simscan was designed that way , but I was 
>> wondering if a patch has been written to deal with this kind of 
>> situation . It would be nice if e-mails were rejected instead of 
>> accepted and bounced .
>>
>> Thank you in advance :)
>>
>>
>>
>>
>>
>
>
> In order to apply spam rules on a per user basis, you will need to 
> demultiplex the message before feeding it to simscan. Usually you can
(Continue reading)

Permalink | Reply | 0 comments |

Gmane