Your message dated Tue, 13 Jun 2006 11:19:48 -0300
with message-id <[EMAIL PROTECTED]>
has caused the Debian Bug report #373159,
regarding amavisd-new: false-positive matches on CLSID banned regexp
to be marked as having been forwarded to the upstream software
author(s) Mark Martinec <[EMAIL PROTECTED]>.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message ---
retitle 373159 amavisd-new: false-positive matches on CLSID banned regexp
tag 373159 - unreproducible moreinfo
tag 373159 + confirmed upstream
severity 373159 important
thanks
Hello Mark,
I am forwarding a bug in the amavisd-new CLSID regexp found by a Debian
user, Martin Schuster, which is also cc'ed.
Please refer to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=373159
for the full bug report, but the important gist of it is in this email.
On Tue, 13 Jun 2006, Martin Schuster wrote:
> > I cannot reproduce this here, amavisd-new 2.4.1 (same regexp).
> >
> How did you try to reproduce this?
I sent mail with such a named attachment through amavisd-new, running in a
up-to-date Debian sid system. I also sent mail which should match other
banned rules to verify if they would be blocked (and they were).
I just noticed your example "{My mailinglist}" would never match anyway. I
tried with "{Mailinglist post" and I could reproduce the bug.
> Which creates a problem, because in
> {something foo bar}
> ^^^^^^^^^^ this part is enough to match, i.e. the regexp right now
> works exactly as if it just was
> \{[0-9a-z]{4,}
> because the rest is
> (...){0,7}\}? which matches an empty string
Your analysis is correct, this match needs to be more strict.
> (without the question mark, it will still match
> {SomeCharactersWithoutSpacesOrStuff}
> which is also bad, now that I think about it...)
Correct. As far as I can find out in the Web, we really should be matching
only {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx} - where x is any alphanumeric
character. Maybe without the last bracket. That would be more than
specific enough that I wouldn't care for anyone hitting a false positive :P
Mark, just how lax are MS Windows apps in interpreting such hideous things
anyway? What sort of corruption of the above format do we need to cather
for because Windows would still execute it (or because viruses are actively
sending it anyway)?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--- End Message ---
