[Replies to many messages....]
I get the impression that the MIME type stuff is wanting to end up
something like a match for (not written as a filter - straight PCRE
style instead) [NB this is intended to be case insensitive, ignore
extra white space - like perl's //ix, ignore # comments]
Content-Type: \s* application/octet-stream; # content-type
\s* # space or newline
(?:file)?name= # filename=/name=
(\"[\"]+\.vbs\" # quoted filename.vbs
|[a-z0-9_.-]+\.vbs) # unquoted filename.vbs
alternatively (could be alternation in regex or in the if construct)
begin \s+ [0-7]{3,4} \s+ # begin octal-mode
(\"[\"]+\.vbs\" # quoted filename.vbs
|[a-z0-9_.-]+\.vbs) # unquoted filename.vbs
in fact as a combined regexp you get
(?:Content-Type: \s* application/octet-stream; # content-type
\s* # space or newline
(?:file)?name= # filename=/name=
|begin \s+ [0-7]{3,4} \s+) # begin octal-mode
(\"[\"]+\.vbs\" # quoted filename.vbs
|[a-z0-9_.-]+\.vbs) # unquoted filename.vbs
[NB (?: is a non capturing bracket - so the filename ends up in $1 ]
yann@??? said:
> Yes there is. Anything with `$message_body contains:' is slow by
> definition. Some ISP (Planet for one) cannot aford to have our service
> crippled by someone who writes a filter which is not optimal for
> speed.
Interesting this one - its going to *have* to be done if there are a rash of varients of this - subject capturing will be just too much a case of being on the losing side of the arms race.
The regexp itself will not be crippling - and its only working over a few K (depending on your settings) of message body. I guess the question is how is the message body being stuffed into $message_body - is it forcing a read each time, is it just a single read and save... [need to go check code]
In any case, you may find this is actually costless if the body file is already opened since the linux clib at least will already have the start of the file mmaped in from when you opened it when processing the file (or it will be mmaped/buffer cached from the SMTP receive/write), and if you go on to attempt to deliver you will definitely be reading that file anyhow... I think you may find that there are no additional kernel read ops done unless the message_body_visible is set rather high (or the servers are running *very* close to the edge anyhow).
BTW message_body_visible probably is going to have to be set to a few K (defaults to 500 bytes)
A slight optomisation is to wrap the whole lot in a if first_delivery - you aren't going to want to do this for every message passing through.
Nigel.
--
[ - Opinions expressed are personal and may not be shared by VData - ]
[ Nigel Metheringham Nigel.Metheringham@??? ]
[ Phone: +44 1423 850000 Fax +44 1423 858866 ]
