Re: [Mimedefang] filtering outlook vulnerabilities

[Edmund]

David F. Skoll wrote:
MIMEDefang by default doesn't address any of those.  It wouldn't be too
hard to code up some Perl that detects and blocks them, but it's not
something I would have time for (nor could I test it, because no one here
runs Outlook.)
If I were to try a go at this, would the
following procedure be correct?
1) Figure out what the vulnerability consists of and
what 'code' is being sent and in what form
2) Do a filter for such a beast

3) test out the filter.

Thanks.

Edmund
___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
[EMAIL PROTECTED]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang

RE: [Mimedefang] CustomRuleSets for SpamAssassin

[Matthew . van . Eerde]

> From: EKB [mailto:[EMAIL PROTECTED]
...

> This is crossover from the Mimedefang list, but it is nice
> enough that I wanted to spread the word.
> 
> http://wiki.spamassassin.org/w/CustomRulesets

Auto-updating spam definitions - what more could one ask for? :)

This does suggest the need for constant false-positive-vigilance on behalf
of those who update the canonical rulesets, though...

Matthew van Eerde
Software Engineer
Hispanic Business Inc.
HireDiversity.com
805.964.4554 x902
[EMAIL PROTECTED]
http://www.hispanicbusiness.com
http://www.hirediversity.com
___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
[EMAIL PROTECTED]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang

[Mimedefang] CustomRuleSets for SpamAssassin

[EKB]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


This is crossover from the Mimedefang list, but it is nice
enough that I wanted to spread the word.

http://wiki.spamassassin.org/w/CustomRulesets

- -- 
EKB
Linux: Because rebooting is for adding new hardware.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAI+I6dY33sSC+/BERAr/5AKCFwRD8DzpkXozXWSjk4kBGVqDZxQCfaIut
MJi1WgbQTJcY9g1RdndiDP8=
=TUlb
-END PGP SIGNATURE-

___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
[EMAIL PROTECTED]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang

Re: [Mimedefang] Re: milter timing out

[Dirk Mueller]

On Friday 06 February 2004 17:05, -ray wrote:

> > and then stop the strace command and send me TRACE.OUT.
> Attached is the strace output file when the system was wedged.  

did he say that you should send it to the mailinglist?


Dirk
___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
[EMAIL PROTECTED]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang

Re: [Mimedefang] Re: milter timing out

[David F. Skoll]

On Fri, 6 Feb 2004, -ray wrote:

> Attached is the strace output file when the system was wedged.  I'm not
> very good at reading strace files, so hopefully you can make sense of it.
> I ran the md-mx-ctrl scan / command a few times also while strace was
> running.  Thanks for any info...

The strace file shows that the multiplexor is working perfectly fine; it's
activating slaves, passing commands back and forth, and everything looks
OK.

The problem is most likely with the milter itself (mimedefang) rather than
the multiplexor.

Regards,

David.
___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
[EMAIL PROTECTED]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang

Re: [Mimedefang] MIME::Parser: can't open tmpfile

[Juergen Georgi]

On Tue 2004-02-03 (12:06), David F. Skoll wrote:
> On Tue, 3 Feb 2004, Juergen Georgi wrote:
> 
> > What baffles me is that three servers with the same software
> > installation and identical filter rules behave differently:
> > One is ok and two are not.
> 
> Something must be different.  Kernel limits on open files?
> Some difference in C library "tmpfile" or "tmpnam" routines?

I'm coming back with some more data. Beside the MIME::Parser
messages there are additional errors logged only on the "bad"
servers:

mimedefang-multiplexor: Slave 5 stderr: cannot write to 
/var/spool/spamassassin/bayes_journal, Bayes db update ignored

The next difference is the size of the bayes_* db files: 
around 40/20 MB (seen/toks) on the "good" server, and 20/85 MB
on the "bad" ones. I recall that I once created the bayes db
from scratch on one of the machines. The big db filess were 
carried over from old SA versions - so maybe they were broken.

Then I did some process tracing of dying mimedefang slaves.
The bayes_journal write erros looked like this

  open64("/var/spool/spamassassin/bayes_journal", O_WRONLY|O_APPEND|O_CREAT, 0666) = 
258
  close(258)  = 0
  write(2, " c a n n o t   w r i t e".., 79)  = 79

and the MIME::Parser errors just before exitus:

  open64("/var/tmp/ywkVayE3", O_RDWR|O_CREAT|O_EXCL, 0600) = 256
  unlink("/var/tmp/ywkVayE3") = 0
  umask(0777) = 077
  umask(077)  = 0777
  fchmod(256, 0600)   = 0
  close(256)  = 0
  getcontext(0xFFBEF410)
  write(2, " M I M E : : P a r s e r".., 51)  = 51
  getcontext(0xFFBEF5A8)
  setcontext(0xFFBEF5A8)
  getcontext(0xFFBEF6D8)
  getcontext(0xFFBEF6D8)
  getcontext(0xFFBEF730)
  getcontext(0xFFBEF5D0)
  getcontext(0xFFBEF5D0)
  llseek(0, 0, SEEK_CUR)  Err#29 ESPIPE
  llseek(255, 0xFD65, SEEK_CUR)   = 803
  _exit(22)

Hmm. All errors happened when the FD numbers where hitting the
256 ceiling. On the good server, the FD number never grew this 
large.

I copied the bayes db files from the good server over to the bad 
ones and - guess what? - the error log messages disappeared. 
It seems that the overly large bayes db files mande MD/SA 
consume more file descriptors. 

But: there is a "ulimit -n 1024" in my mimedefang start script,
so there should be no shortage of file descriptors. Btw,
"mimedefang -C" didn't help either. I'm afraid that my Perl 
installation is broken.

And: why is MD/SA using /var/tmp for creating temp files?
How can I change this to /tmp, which is memory mapped?
Setting TMPDIR has no effect.

Apologizing for the long posting.

Regards,

-Juergen
___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
[EMAIL PROTECTED]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang

Which milter t/o generates 'timeout before data read' error? was: Re: [Mimedefang] milter timing out.

[Jon R. Kibler]

"Jon R. Kibler" wrote:
> 
> >
> > Jan 31 20:51:03 norm sm-mta[27815]: i112jv3O027815: Milter (mimedefang):
> > timeout before data read
> > Jan 31 20:51:03 norm sm-mta[27815]: i112jv3O027815: Milter (mimedefang):
> > to error state
> 

I asked this question earlier, but I think it got lost in other parts of the 
discussion and never got answered: Regarding the above error messages... which milter 
timeout value (C,S,R, or E) effects the 'timeout before data read' error? That is, 
which ones should be increased to eliminate this error?

--
Jon R. Kibler
Chief Technical Officer
A.S.E.T., Inc.
Charleston, SC  USA
(843) 849-8214




==
Filtered by: TRUSTEM.COM's Email Filtering Service
http://www.trustem.com/
No Spam. No Viruses. Just Good Clean Email.

___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
[EMAIL PROTECTED]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang

Re: [Mimedefang] Looking for more ramdisk benefits

[Jon R. Kibler]

Peter Campion-Bye wrote:
> 
> I moved /var/spool/MIMEDefang to a ramdisk and got a 20% improvement in
> scan time (It's a slow old disk in the box)
> Before I spend ages experimenting, has anybody found any worthwhile
> improvement by moving other stuff to ramdisk, the SA rules for example, (I
> expect these are just read once and cached) How about the clamav db?
> Is there anything that's read into memory off the disk on every message?
> Thanks

Please see my posting Wednesday under the thread 'no free slaves...' for some 
additional things to cache.

--
Jon R. Kibler
Chief Technical Officer
A.S.E.T., Inc.
Charleston, SC  USA
(843) 849-8214





==
Filtered by: TRUSTEM.COM's Email Filtering Service
http://www.trustem.com/
No Spam. No Viruses. Just Good Clean Email.

___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
[EMAIL PROTECTED]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang

Re: [Mimedefang] uv scan is hanging

[Alexander Dalloz]

Am Fr, den 06.02.2004 schrieb Andrew Jayes um 15:44:
> Hi,
>   Well if my other post turns up, I can say that I have now found
> my .sock and got everything sorted. The next problem I have is that when
> I try to send a mail (using telnet session) in to the server it seam's
> uvscan is hanging, this means that in the session I can't terminate the
> mail with '.' eventually I just get 'try again later'. On the mail box
> using ps axf I can see that uvscan is has been running for 10 minutes.
> 
> I'm running fedora core 1
> 
> Anyone got any suggestions?
> 
> Andrew 

You might face this know issue:

https://knowledgemap.nai.com/phpclient/viewKDoc.aspx?externalID=KB_NAI31418&sliceID=&docID=KC.KB_NAI31418&url=kb/kb_nai31418.xml&dialogID=152376&docType=DOC_KnowledgeBase&userType=3&iterationID=1&sessionID=Anonymous|1768269092&userID=&docName=Solution%20ID%20NAI31418%20-%20VirusScan%20for%20Unix%20does%20not%20run%20on%20Red%20Hat%20Linux%209&sourceKmap=&viewFrom=Main

Sorry, this URI is that long. Btw. on my FC1 system uvscan works
properly.

Alexander


-- 
Alexander Dalloz | Enger, Germany | GPG key 1024D/ED695653 1999-07-13
Fedora GNU/Linux Core 1 (Yarrow) on Athlon CPU kernel 2.4.22-1.2149.nptl
Sirendipity 16:43:44 up 6 days, 15:43, load average: 0.27, 0.29, 0.20 
   [ ÎÎÏÎÎ Ï'ÎÏÏÎÎ - gnothi seauton ]

___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
[EMAIL PROTECTED]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang

Re: [Mimedefang] Looking for more ramdisk benefits

[Brenden Conte]

The only benifits you will really see from using a ramdisk are for
things that involve many read/writes.  Files that are only read (even if
every time) will be cached by the OS (lack of memory and large files
aside, in which case a ramdisk is a bad idea anyway), making the ramdisk
unnessesary.  Things like the MIMEDefang directory are perfect, because 

a) The files are created, read, written, and deleted quickly and often,
and
b) In the event of a system failure, the data in that directory is
non-critical.

The only other directory we've ramdisk'ed is our AV temp directory,
where attachments are written (or extracted) to be scanned, then
deleted.  Everything else is either critical information (i.e. the
sendmail mqueue) or read-once.

-Brenden

On Fri, 2004-02-06 at 08:54, Peter Campion-Bye wrote:
> I moved /var/spool/MIMEDefang to a ramdisk and got a 20% improvement in
> scan time (It's a slow old disk in the box)
> Before I spend ages experimenting, has anybody found any worthwhile
> improvement by moving other stuff to ramdisk, the SA rules for example, (I
> expect these are just read once and cached) How about the clamav db?
> Is there anything that's read into memory off the disk on every message?
> Thanks
> 
> mimedefang 2.39  sendmail 8.12.9   clamav 0.65  spamassassin 2.63
> 
> ___
> Visit http://www.mimedefang.org and http://www.canit.ca
> MIMEDefang mailing list
> [EMAIL PROTECTED]
> http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
-- 
Brenden Conte
System Programmer, C&CT
Rensselaer Polytechnic Institute
(518)276-2540
-- 
Brenden Conte
System Programmer, C&CT
Rensselaer Polytechnic Institute
(518)276-2540

___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
[EMAIL PROTECTED]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang

Re: [Mimedefang] Looking for more ramdisk benefits

[Justin]

On Fri, 6 Feb 2004, David F. Skoll wrote:

> You can split the Sendmail queue so that the "df" and "qf" files (which
> *must* survive a crash) are on permanent storage, but the temporary
> "xf" transaction files are on a ramdisk.  Someone else mentioned
> this; I don't have the reference offhand.

Taken from O'Reilly's "sendmail Cookbook" chapter 9, section 2 by Craig
Hunt (highly recommended BTW):

"
Create a new queue directory structure with separate directories for df, 
qf, and xf queue files.

umask 077
mkdir /var/spool/mqueue.new
cd /var/spool/mqueue.new
mkdir df qf xf

Move the old queue directory out of the way so that the new queue 
directory structure can be given the pathname defined by the 
QueueDirectory option in the sendmail.cf file.

mv /var/spool/mqueue /var/spool/mqueue.old
mv /var/spool/mqueue.new /var/spool/mqueue

Start another copy of sndmail as a queue runner to drain the old queue.  
Use the -O arguement on the sendmail command line to point the quue runner 
to the old queue.

sendmail -L sm-oldq -q15m -O QueueDirectory=/var/spool/mqueue.old
"

Sendmail will automagically use the df, qf and xf directories if they 
exist within QueueDirectory.  Knowing this you can easily mount a tmpfs 
volume to xf to reap the benefits.  Don't forget the queue runner for the 
old queue directory though.

HTH
 Justin

PS==> Did I mention that it's an excellent book?  

http://www.oreilly.com/catalog/sendmailckbk/

___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
[EMAIL PROTECTED]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang

Re: [Mimedefang] Looking for more ramdisk benefits

[WBrown]

[EMAIL PROTECTED] wrote on 02/06/2004 09:48:16 
AM:
> You can split the Sendmail queue so that the "df" and "qf" files (which
> *must* survive a crash) are on permanent storage, but the temporary
> "xf" transaction files are on a ramdisk.  Someone else mentioned
> this; I don't have the reference offhand.

This documented in the book "sendmail Performance Tuning" by Nick 
Christenson (Addison Wesley).

It's probably noted elsewhere, but that's where I read it.
___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
[EMAIL PROTECTED]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang

Re: [Mimedefang] Looking for more ramdisk benefits

[Chris Myers]

- Original Message - 
From: "Kevin A. McGrail" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, February 06, 2004 9:00 AM
Subject: Re: [Mimedefang] Looking for more ramdisk benefits


> > Bayes db lookups hit the disk on every message. I'm thinking about
> > moving bayes_path entirely to a tmpfs. [...]
> > Has anyone done this before?
>
> I've always wondered if the kernel disk caching method (linux) is
efficient
> enough to bypass the need to use a ram disk for a static (esque) file such
> as this?
>
> Any comments?


Disk caching is primarily for disk reads, and the Bayes database has a
pretty fair number of writes as well.  I saw disk I/O drop *tremendously*
when I moved the Bayes database to a ramdisk ... but I also have a large
Bayes database (90MB now that they've fixed expires, 200+MB before!).

Chris Myers
Networks By Design


___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
[EMAIL PROTECTED]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang

Re: [Mimedefang] Looking for more ramdisk benefits

[Kevin A. McGrail]

> Bayes db lookups hit the disk on every message. I'm thinking about
> moving bayes_path entirely to a tmpfs. Of course there must be
> a mechanism to save the precious bayes data across reboots - maybe
> with one or two snapshot backups per day to persistant storage.
>
> Has anyone done this before?

I've always wondered if the kernel disk caching method (linux) is efficient
enough to bypass the need to use a ram disk for a static (esque) file such
as this?

Any comments?

KAM

___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
[EMAIL PROTECTED]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang

Re: [Mimedefang] 12,000 /var/spool/MIMEDefang/mdefang-xxxxxxxxxxxxxx directories in 7 days

[David F. Skoll]

On Fri, 6 Feb 2004 [EMAIL PROTECTED] wrote:

> Yes, I knew this was a band-aid solution.  Are there any command
> line swtiches for MIMEDefang that might be thrown to shed more light
> on the cause?

Not really.  It may be a Milter bug; if the Milter callbacks don't happen
as promised (if, for example, a thread gets killed without the cleanup
callback being invoked), the directories will hang around.

> As you pointed out above, perhaps the rm -r command could be used
> instead of rmdir within MIMEDefang.

MIMEDefang cleans up recursively; the source code is in rm_r.c If you
supply --enable-cleanup-with-rm to ./configure, then it cleans up by
forking/execing "rm -r -f " instead of using the built-in C code.
However, I doubt this will solve the problem.

[...]

> I have to say that it is here to stay, rich text messages, that is.

Not on this list.  And once enough people (or a big enough ISP) realize
that HTML mail is a security risk and a perfect spam-shrouding tool, things
will start to change.

Regards,

David.
___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
[EMAIL PROTECTED]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang

Re: [Mimedefang] Looking for more ramdisk benefits

[Chris Myers]

- Original Message - 
From: "Juergen Georgi" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, February 06, 2004 8:42 AM
Subject: Re: [Mimedefang] Looking for more ramdisk benefits


> > I moved /var/spool/MIMEDefang to a ramdisk and got a 20% improvement in
> > scan time (It's a slow old disk in the box)
> > Before I spend ages experimenting, has anybody found any worthwhile
> > improvement by moving other stuff to ramdisk, [...]
>
> Bayes db lookups hit the disk on every message. I'm thinking about
> moving bayes_path entirely to a tmpfs. Of course there must be
> a mechanism to save the precious bayes data across reboots - maybe
> with one or two snapshot backups per day to persistant storage.
>
> Has anyone done this before?

Yes, I have done this and it's incredibly helpful on a higher-volume system.

You should at least write scripts that do roughly:

1) At system boot:
- Mount the tmpfs
- Copy the backup bayes database to the tmpfs

2) At system shutdown:
- Copy the bayes database to the backup location
- Dismount the tmpfs

If you lose a few days (or, often, a few weeks!) of Bayes database it's not
a problem.  Losing a few months, or all of it, would generally be considered
"bad".

Do make sure you have enough RAM to keep everything from swapping and
paging.  The moment a system starts swapping and paging, performance will
drop in the the toilet.  I probably wouldn't even consider this trick with
less than 512MB of RAM (and preferably 1GB).

Chris Myers
Networks By Design


___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
[EMAIL PROTECTED]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang

[Mimedefang] FW: missing a .sock?

[Andrew Jayes]

Hi,
I seam to be missing mimedefang.sock. under
/var/spool/MIMEDefang I have:
 mimedefang-multiplexor.pid mimedefang-multiplexor.sock and
mimedefang.pid

 but in the sendmail config I have the:
 INPUT_MAIL_FILTER(`mimedefang',
`S=unix:/var/spool/MIMEDefang/mimedefang.sock, F=T, T=S:1m;R:1m')

Can any one fill me in as to where I can generate this file and what id
actually does.

Cheers

andi

___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
[EMAIL PROTECTED]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang

Re: [Mimedefang] 12,000 /var/spool/MIMEDefang/mdefang-xxxxxxxxxxxxxx directories in 7 days

[postmaster]

Thanks for the reply David.

[EMAIL PROTECTED] wrote on 02/05/2004 20:28:30:

> On Thu, 5 Feb 2004 [EMAIL PROTECTED] wrote:
> 
> > When I took a look in the /var/spool/MIMEDefang directory, I was
> > quite surprised to see over 12,000 directories with timestamps
> > spanning the previous 7 days.
> 
> > It would appear that they weren't deleted because the directory
> > (still) contained contents.
> 
> That's odd; recent versions of MIMEDefang are usually good about cleaning
> up, even under heavy load.
> 
> Any directories older than about an hour are dead anyway; you can run this
> from cron periodically to clean up:
> 
> find /var/spool/MIMEDefang -name 'mdefang-*' -type d -mtime +1 | xargs rm -r

Yes, I knew this was a band-aid solution.  Are there any command line swtiches for 
MIMEDefang that might be thrown to shed more light on the cause?  Output info to a 
debugging file perhaps?  I'd rather like to squash the cause rather than treat the 
symptom.

As you pointed out above, perhaps the rm -r command could be used instead of rmdir 
within MIMEDefang.  Then the directory structure wouldn't have to be recursively 
removed to complete cleanup.  The only reason I could think of not doing this is 
because the directory was to be purposely left in place as a trail, in the event of 
some kind of an error, like what I have been experiencing.

> > Oh, by the way,... Why doesn't the mailing list take advantage of
> > the section in MIMEDefang to strip out the html sections of MIME
> > messages?
> 
> It's a conspiracy to get people not to use HTML mail...

I have to say that it is here to stay, rich text messages, that is.

> Regards,
> 
> David.

-- James

 o o o o o o o . . .   ___ ===_T___
   o  _|James Madill | |Duke U. Health Sys|
>.][__n_n_| D[  |  |[EMAIL PROTECTED]| |  (919) 286-6384  |
 (|__|_[/]_|_|_|__|
_/oo  O-O-O  `  oo oo  'o^o^o   o^o^o` 'o^oo^o`
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-


___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
[EMAIL PROTECTED]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang

Re: [Mimedefang] unwanted lines in syslog

[Jim McCullars]

On Fri, 6 Feb 2004, Michal Szymanski wrote:

> The syslogged info on Solaris includes (IMHO quite unneccessary) lines like:
>
> ... Milter add: header: X-Scanned-By: MIMEDefang 2.39
> ... Milter change: header  MIME-Version: from 1.0 to 1.0
> ... Milter change: header  X-Spam-Status: from No to Yes
> etc.

   This is addressed in the FAQ:

http://www.mimedefang.org/node.php?id=22

(it's sendmail, not MD).

Jim McCullars


___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
[EMAIL PROTECTED]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang

Re: [Mimedefang] Looking for more ramdisk benefits

[David F. Skoll]

On Fri, 6 Feb 2004, Peter Campion-Bye wrote:

> I moved /var/spool/MIMEDefang to a ramdisk and got a 20% improvement in
> scan time (It's a slow old disk in the box)
> Before I spend ages experimenting, has anybody found any worthwhile
> improvement by moving other stuff to ramdisk, the SA rules for example,

You won't see much benefit from that, and if you're using the embedded
Perl interpreter, you won't see any benefit at all.

> Is there anything that's read into memory off the disk on every message?

You can split the Sendmail queue so that the "df" and "qf" files (which
*must* survive a crash) are on permanent storage, but the temporary
"xf" transaction files are on a ramdisk.  Someone else mentioned
this; I don't have the reference offhand.

Regards,

David.
___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
[EMAIL PROTECTED]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang

[Mimedefang] uv scan is hanging

[Andrew Jayes]

Hi,
Well if my other post turns up, I can say that I have now found
my .sock and got everything sorted. The next problem I have is that when
I try to send a mail (using telnet session) in to the server it seam's
uvscan is hanging, this means that in the session I can't terminate the
mail with '.' eventually I just get 'try again later'. On the mail box
using ps axf I can see that uvscan is has been running for 10 minutes.

I'm running fedora core 1

Anyone got any suggestions?

Andrew 

___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
[EMAIL PROTECTED]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang

Re: [Mimedefang] Looking for more ramdisk benefits

[Juergen Georgi]

On Fri 2004-02-06 (13:54), Peter Campion-Bye wrote:
> 
> I moved /var/spool/MIMEDefang to a ramdisk and got a 20% improvement in
> scan time (It's a slow old disk in the box)
> Before I spend ages experimenting, has anybody found any worthwhile
> improvement by moving other stuff to ramdisk, the SA rules for example, (I
> expect these are just read once and cached) How about the clamav db?
> Is there anything that's read into memory off the disk on every message?
> Thanks
> 
> mimedefang 2.39  sendmail 8.12.9   clamav 0.65  spamassassin 2.63

Bayes db lookups hit the disk on every message. I'm thinking about
moving bayes_path entirely to a tmpfs. Of course there must be 
a mechanism to save the precious bayes data across reboots - maybe 
with one or two snapshot backups per day to persistant storage.

Has anyone done this before?

Regards,

-Juergen
___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
[EMAIL PROTECTED]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang

[Mimedefang] unwanted lines in syslog

[Michal Szymanski]

Hi,

I have just succeeded in installing Mimedefang/Spamassassin/File::Scan
on a Solaris 2.5.1 machine which still handles most of our dept. mail.

Everything seems to work fine but I noticed one difference as compared
to a test install on a Fedora FC1 Linux machine:

The syslogged info on Solaris includes (IMHO quite unneccessary) lines like:

... Milter add: header: X-Scanned-By: MIMEDefang 2.39
... Milter change: header  MIME-Version: from 1.0 to 1.0
... Milter change: header  X-Spam-Status: from No to Yes
etc.

All config files (mimedefang-filter, local.cf, sa-mimedefang.cf)
are identical on both machines. Syslog.conf contains "mail.debug"
on Solaris and "mail.*" on Linux machine which AFAIK means the same
level of logging.

Any hints how to get rid of these lines would be appreciated.

regards, Michal.

-- 
  Michal Szymanski ([EMAIL PROTECTED])
  Warsaw University Observatory, Warszawa, POLAND
___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
[EMAIL PROTECTED]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang

[Mimedefang] Looking for more ramdisk benefits

[Peter Campion-Bye]

I moved /var/spool/MIMEDefang to a ramdisk and got a 20% improvement in
scan time (It's a slow old disk in the box)
Before I spend ages experimenting, has anybody found any worthwhile
improvement by moving other stuff to ramdisk, the SA rules for example, (I
expect these are just read once and cached) How about the clamav db?
Is there anything that's read into memory off the disk on every message?
Thanks

mimedefang 2.39  sendmail 8.12.9   clamav 0.65  spamassassin 2.63

___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
[EMAIL PROTECTED]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang

Re: [Mimedefang] filtering outlook vulnerabilities

[David F. Skoll]

On Fri, 6 Feb 2004, Edmund wrote:

> Outlook 'CR vulnerability'
> Outlook 'Space Gap' vulnerability
> Outlook 'Blank Folding' Vulnerability
> Outlook 'Boundary Space Gap' Vulnerability
> Outlook 'Long Boundary' Vulnerability

MIMEDefang by default doesn't address any of those.  It wouldn't be too
hard to code up some Perl that detects and blocks them, but it's not
something I would have time for (nor could I test it, because no one here
runs Outlook.)

Regards,

David.
___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
[EMAIL PROTECTED]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang

Re: [Mimedefang] checking the body and the headers for strings?

[Jonas Eckerman]

Please, use a mailer that handles threading.

>  Well, one reason is that in all my tests I found out that
>  Spamassasin tookup too much memory to operate

The one reason I listed in my answer. :-)

>  So how can I get those codes to work in mimedefang-filter?

Maybe something like this in filter_begin (note, the code below is completely untested 
and written before I've finished my first cup of coffee, don't trust it too much):

if (open (INF, "./HEADERS")) {
my $bad = 0;
while (my line = ) {
$line =~ s/\n//g;
if ($line =~ /^Subject:\s+.*hastalavistababy.*$/) {
$bad = 1;
last;
}
}
close(INF);
return action_discard('Bad, bad header!') if ($bad);
}

if (open (INF, "./INPUTMSG")) {
my $bad = 0;
while (my line = ) {
$line =~ s/\n//g;
if ($line =~ /hastalavistababy/) {
$bad = 1;
last;
}
}
close(INF);
return action_discard('Bad, bad body!') if ($bad);
}

Regards
/Jonas

-- 
Jonas Eckerman, [EMAIL PROTECTED]
http://www.fsdb.org/


___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
[EMAIL PROTECTED]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang

Re: [Mimedefang] 12,000 /var/spool/MIMEDefang/mdefang-xxxxxxxxxxxxxx directories in 7 days

[Xiaoyan Ma]

When I took a look in the /var/spool/MIMEDefang directory, I was quite 
surprised to see over 12,000 directories with timestamps spanning the 
previous 7 days.

It would appear that they weren't deleted because the directory (still) 
contained contents.
This happened to me when we first implemented MD.  I was running with -d 
flag, enable debugging.

Xiaoyan 

___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
[EMAIL PROTECTED]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang