On Saturday, January 28, 2006 12:18 AM -0500 "Kevin A. McGrail" <kmcgrail <at> pccc.com> wrote: > If you would like to use the system, email me your daily mail volume and > I'll forward your request. If approved, I'll send you the MD code and SA > rule files. Why not add it to the wiki?
On Monday, January 30, 2006 2:48 PM +0200 ms <at> interspace.net wrote: > Is everybody ready for the next wave of viruses?? > Kama Sutra worm set to bite next week... > http://news.zdnet.com/2100-1009_22-6031881.html Symantec's detailed analysis: <http://securityresponse.symantec.com/avcenter/venc/data/w32.blackmal.e <at> mm.html>
Matthew.van.Eerde <at> hbinc.com wrote: >>I think this would probably just yield the public IP address of your >>DNS resolver, unless you queried the service's own DNS server >>directly. >Good point. Still useful if /etc/resolv.conf is "nameserver 127.0.0.1" but less generally useful than I had thought. Can't you force the local resolver to do the recursion itself? -Philip
On Tue, Jan 31, 2006 at 05:16:58PM -0600, Sean Ware wrote: > > They'd have to, or the TCP session would break. > > That's what I was thinking. I was just trying to determine How Evil > they actually were. Or if some other TCP magic was going on in the > round-robin. -- At least some small shred of my sanity is retained. That shred of sanity would quickly wash away once you actually use one of those devices and tried to trouble shoot problems with it - especially if loadbalanced boxes are trying to contact another virtual service that's really serviced by another box but on the same network. The silent changes to TCP headers are almost impossible to comprehend. Been there, done that, got the straightjacket. That said, having a bunch of sendmail/MD/SA boxes behind a loadbalancer behaves quite good. If one machine accidentally starts eating itself because some poor schmuck uploaded an mp3 file as .procmailrc, which procmail always seems to see as an instruction to start forkbombing and maillooping itself to oblivion, then one box goes down, but nobody suffers because the machine will be taken out of the pool, and the service as a whole just continues to run. (Well, you'd have to remove the erroneous .procmailrc file before this user gets more mail and takes more boxes down). -- -- #!perl -wpl # mmfppfmpmmpp mmpffm <pmmppfmfpppppfmmmf <at> fpffmm4mmmpmfpmf.ppppmf> $p=3-2*/[^\W\dmpf_]/i;s.[a-z]{$p}.vec($f=join('',$p-1?chr(sub{$_[0]*9+$_[1]*3+ $_[2]}->(map{/p|f/i+/f/i}split//,$&)+97):qw(m p f)[map{((ord$&)%32-1)/$_%3}(9, 3,1)]),5,1)='`'lt$&;$f.eig; # Jan-Pieter Cornet(Continue reading)
The project can only pay for so much bandwidth and it's not a solution that scales to multipoint distribution like an RBL via DNS. So at the moment, they are handpicking the people who get to use the system. Regards, KAM > > If you would like to use the system, email me your daily mail volume and > > I'll forward your request. If approved, I'll send you the MD code and SA > > rule files. > > Why not add it to the wiki?
Hello,
I tried to compile mimedefang from source. It binds agains
libmilter.a, which used libldap . In configure.in of Mimedefang this is
foreseen with the lines:
AC_DEFUN(MD_SM_LDAP,[
AC_MSG_CHECKING([whether libsm requires -lldap])
RESULT=`$NM $LIBSM | grep ldap_`
if test -z "$RESULT" ; then
AC_MSG_RESULT(no)
else
AC_MSG_RESULT(yes)
LIBS="$LIBS -lldap -llber"
fi
])
however the string "ldap|" is not contained in the ./configure supplied
with mimedefang 2.55 . I tried to autoreconf, and got the error message:
root <at> aegeeserv:/src/mimedefang-2.55# autoreconf
configure.in:634: warning: underquoted definition of MD_MILTER_SFIO
run info '(automake)Extending aclocal'
or see http://sources.redhat.com/automake/automake.html#Extending-aclocal
configure.in:645: warning: underquoted definition of MD_SM_LDAP
configure.in:656: warning: underquoted definition of MD_MILTER_SM
/usr/share/aclocal-1.9/xmms.m4:17: warning: underquoted definition of
XMMS_TEST_VERSION
[...]
When I compile mimedefang 2.55, I get
gcc -g -O2 -Wall -Wstrict-prototypes -pthread -o mimedefang
(Continue reading)
I attempted to upgrade my two mail relays to MIMEDefang 2.55 (from
2.54), one running FreeBSD 5.4, the other 4.10. Compilation of
mimedefang.c succeeds on 5.4, but fails on 4.10. Adding <sys/types.h>
before <sys/socket.h> in mimedefang.h and bracketing { } the section
from line 403 to about 423 in mimedefang.c makes it compile, but since
I'm not a heavy-duty C programmer and haven't gone thru the entire
mimedefang code, I'm reluctant to use it.
I don't normally upgrade the OS on my systems until we get new systems
under our hardware replacement schedule unless there's a serious issue,
since they're in production and there's a risk of extended downtime. I
suppose I"ll be upgrading sooner this time.
Ione
_________________________________
Ione Kotis
Systems Engineer
Information Technology Services
Systems and Network Administration
Sinclair Community College
444 W Third Street
Dayton OH 45402
937/512-4552
ione.kotis <at> sinclair.edu
_________________________________
-----Original Message-----
From: mimedefang-bounces <at> lists.roaringpenguin.com
[mailto:mimedefang-bounces <at> lists.roaringpenguin.com] On Behalf Of David
(Continue reading)I've had a couple of spams drop in my inbox recently, and at first, I couldn't see how they made it past SA. I looked at the headers, and to my surprise, the message hadn't been scanned by Spamassassin(!). Why? How? I looked further, and noticed that one message was 800K bytes, and the other 140K. The first had an attached .wmv file (hopefully not one of _those_ .wmv files, but I didn't click on it to find out). Both messages avoided being scanned by SA because they were larger than the 100K limit we currently impose via MdF. What to do? I can bump the size limit, or have no limit at all. I could consider building a temporary copy of the message with non text and/or html attachments removed, and feed that to SA, although that sounds a bit complicated and computationally expensive. BTW, a couple of years ago, I experiment with simpiy peeling off the first N bytes off the front of large messages and tacking on the last N bytes (where N = approx. 50K). This actually worked rather well, modulo the occassional malformed MIME content. I could do that, but it is a bit of hack, and could result in having some valid ham messages mis-filed as spam, partly because the MIME parts are garbled. Thoughts?
On 2/1/06, Gary Funck <gary <at> intrepid.com> wrote: > > > I've had a couple of spams drop in my inbox recently, > and at first, I couldn't see how they made it past SA. > I looked at the headers, and to my surprise, the message > hadn't been scanned by Spamassassin(!). Why? How? > I looked further, and noticed that one message was 800K > bytes, and the other 140K. The first had an attached > .wmv file (hopefully not one of _those_ .wmv files, but > I didn't click on it to find out). > Well depending on how patched your system is.. and what application you are using for email you do not have to click on the wmv file. Just having some clients process the email can cause problems (according to one write up about WMV). I would recommend that you put wmv on the extensions block list and your problem is solved. I would also recommend a grey-list or other mechanism. -- Stephen J Smoogen. CSIRT/Linux System Administrator
> From: Stephen J. Smoogen > Sent: Wednesday, February 01, 2006 4:22 PM > > Well depending on how patched your system is.. and what application > you are using for email you do not have to click on the wmv file. Just > having some clients process the email can cause problems (according to > one write up about WMV). I would recommend that you put wmv on the > extensions block list and your problem is solved. Good idea for .wmv files, but still doesn't address the correct action for spam files that exceed the cutoff. > > I would also recommend a grey-list or other mechanism. > Yup, we do that, and it works well.
RSS Feed49 | |
|---|---|
21 | |
119 | |
8 | |
23 | |
13 | |
10 | |
26 | |
42 | |
81 | |
13 | |
48 | |
43 | |
36 | |
22 | |
53 | |
41 | |
11 | |
59 | |
41 | |
43 | |
31 | |
12 | |
43 | |
11 | |
14 | |
7 | |
70 | |
11 | |
23 | |
15 | |
53 | |
24 | |
32 | |
78 | |
83 | |
46 | |
46 | |
65 | |
230 | |
92 | |
69 | |
144 | |
18 | |
46 | |
61 | |
64 | |
67 | |
75 | |
56 | |
39 | |
58 | |
25 | |
54 | |
86 | |
122 | |
48 | |
51 | |
52 | |
61 | |
76 | |
90 | |
50 | |
71 | |
95 | |
82 | |
90 | |
64 | |
117 | |
124 | |
228 | |
76 | |
300 | |
210 | |
211 | |
270 | |
307 | |
240 | |
282 | |
193 | |
129 | |
86 | |
138 | |
215 | |
204 | |
227 | |
238 | |
172 | |
512 | |
249 | |
184 | |
198 | |
398 | |
204 | |
210 | |
389 | |
372 | |
330 | |
342 | |
243 | |
171 | |
210 | |
419 | |
345 | |
569 | |
511 | |
468 | |
512 | |
483 | |
691 | |
964 | |
851 | |
321 | |
1 |
