Hi, I've been working with both Davide and Don Drake on filter issues involving XMail and Solaris. It involves SpamAssassin and 1.18, but I also tested it with other filters and observed similar behavior. The behavior is as follows:
1. Everything seems okay at first. 2. At some point, XMail would no longer properly filter the mail, and all in/outbound mail would no longer be delivered (stuck in the queue and pop3 connects fail). 3. Any attempt to stop XMail with /etc/init.d/xmail at that point would kill all XMail processes except the root XMail process which appears to be hung. The good news is that this appears to be solved with the lastest version/install of XMail 1.18 (it's been running for over a week now). This was accomplished in the following way. 1. Bulid and install XMail (after stopping it, of course). 2. Remove the entire spool except for local and temp (allows XMail to rebuild the spool). 3. Restart XMail. I'm not sure of the necessity of step 2 for most users. I'm not positive, but I think I clobbered my own spool. Hence the need for a rebuild. It can't hurt, though. If you close port 25 for a sec, stop and restart XMail, and wait a few, your spool should clear out (you don't want to delete user's mail). Hope this helps. I don't know how long ago you got the XMail 1.18 Beta. Grab the latest and see what happens. - Kelly > Unfortunately the messages that got through were quarantined and the users > = > always empty their quarantine....darn it. Couldn't look for the tag in = > the header. Now another bad one hasn't come through (that we've been told > = > about). Even tried to restore from the Norton backup but it couldn't = > restore the infected message so I couldn't see squat. > > I'll offer this info though to see if it helps figure this out (although I > = > believe one person said yesterday that they've experienced this as well = > with the huge MyDoom load). > > > A few days ago I requested info regarding how to upgrade to 1.18, sounded > = > simple enough so I upgraded the backup server (which is ONLY a backup = > server, it only hosts the main domain for which only a postmaster account > = > is setup).=20 > > When users on the primary server began receiving virii, I checked the = > backup server just for giggles and found that the anti-virus filter hadn't > = > logged any entries since 2/9. The SMTP didn't log anything on 2/10 but = > did on 2/11. I shut down the backup yesterday (when these virus things = > started happening) to see if additonal virus were passed through on the = > Primary, after I had shut down the backup (or so it seems) there weren't > = > any more virii received by the Primary. Checking the smtp log on the = > backup server (checked it this morning after removing the connection to = > the network) for 2/12 though didn't show any messages passed to the users > = > that received the infected messages. Dead end here I assume. > > I fired this server up today with the nic unplugged and the antivirus = > filter fired off against items that must have been spooled. First time = > it's activated since 2/9. > > Now, for the other twist. I upgraded the primary server last night to = > 1.18. After doing so, the SMTP server accepted messages from the internet > = > and clients could send messages but all sent messages stayed in the = > queue's. Even if sending a message to someone on the same domain. The = > client could connect via POP3 but would say "no messages found". I put = > 1.17 back into operatioin and all of the messages were cleared from the = > queue and delivered properly. > > I upgraded both servers exactly like this: > > had xmail-1.18.tar.gz in /usr/src/xmail118 > from the /usr/src/xmail118 directory ran=20 > #gunzip xmail-1.18.tar.gz > #tar -xsvf xmail-1.18.tar > # cd xmail-1.18 > #makefile -f Makefile.lnx > after compiling I went to /var and ran > #cp -a MailRoot /var/MailRoot.1.17 > # cp MailRoot/bin > # mv XMail Xmail.1.17 > # mv CtrlClnt CtrlClnt.1.17 > # mv sendmail sendmail.1.17 > #mv MkUsers MkUsers.117 > # mv XMCrypt XMCrypt.1.17 > # cd //usr/src/xmail118/xmail-1.18 > # cp XMail CtrlClnt sendmail XMCrypt MkUsers /var/MailRoot/bin/ > > I then restarted xmail with > #/etc/rc.d/init.d/xmail start > > This is correct, no? > > Another strange thing, I've found that using "/etc/rc.d/init.d/xmail stop" > = > with 1.18 does not stop xmail. It says "Stopping XMail server:" but it = > just hangs there. This happened on both primary and backup. =20 > > I switched both back to 1.17 and both servers can shutdown xmail properly > = > again. > > I'm going to put the backup server back on the network and see if we get > = > any virii through today. If all is well through the weekend I may put = > 1.18 back onto the backup server to see if I can re-create the virus = > infections. > > Of course, this could all just be a strange coincidence, we all know I'm > = > not even close to being any good with Linux/XMail or knowing how/why = > things happen, but I'll say this much, I'm sure learning a bunch :) > > Thanks all! > > > > >>>> [EMAIL PROTECTED] 02/12/04 12:53PM >>> > Dale Qualls schreef: > >> Is there a limit to the number of times the av-filter can be called and >> = > =3D >> will mail bypass it if it's busy or runs out of threads? >>=20 >> In the last couple of days we've have many copies of mydoom get through >> = > to =3D >> the user (where the desktop AV stopped it) but we're still having copies >> = > =3D >> caught by the av-filter. >>=20 >> Is anyone else experiencing this? >>=20 >> Thx! >>=20 >> RH 8.0 on P4 2.4GHZ with tons o' RAM (could be a 2.6, I don't recall) >> xmail 1.17 >> clamav >> Peter's av-filter >> Only a couple hundred of messages per day. > > I have never saw this behaviour here. Since the script is using random=20 > path's for working I don't see what can go wrong at this time. Is the=20 > X-AV-Scanned: header in the infected message? > > --=20 > Groeten, > Peter > > > Always remember you're unique, just like everyone else. > > - > - Heb je een Dreambox 7000S ? > - Kijk eens op http://www.dreamvcr.com=20 > - Kijk ook op http://www.lindeman.org=20 > - ICQ 22383596 > - Uptime lindeman.org - 34 days, 21 hours and 48 minutes, 0 users logged > = > in. > > - > To unsubscribe from this list: send the line "unsubscribe xmail" in > the body of a message to [EMAIL PROTECTED] > For general help: send the line "help" in the body of a message to > [EMAIL PROTECTED] > > - > To unsubscribe from this list: send the line "unsubscribe xmail" in > the body of a message to [EMAIL PROTECTED] > For general help: send the line "help" in the body of a message to > [EMAIL PROTECTED] > > - To unsubscribe from this list: send the line "unsubscribe xmail" in the body of a message to [EMAIL PROTECTED] For general help: send the line "help" in the body of a message to [EMAIL PROTECTED]
