Re: [Mimedefang] compare mimedefang to mailscanner
On 1/16/07, David F. Skoll <[EMAIL PROTECTED]> wrote: 1) Disk I/O: MIMEDefang will use less disk I/O than Mailscanner because you're not queueing every mail message twice. In fact, if you have a modern version of Sendmail with SuperSafe set to PostMilter and MIMEDefang rejects or tempfails a message, that queue file won't be sync'd to disk. Sorry for going OT, but this is the first I'd heard of the PostMilter option. Is there any reason not to enable that with MIMEDefang? (Even if the server crashes before the queue is sync'd, the sender will retry, so no data loss should occur, correct?) Josh Kelley ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] File descriptors and error handling
On 11/3/06, David F. Skoll <[EMAIL PROTECTED]> wrote: Josh Kelley wrote: > Any other ideas on how to track this problem down? Not really.. Try turning of embedded Perl. If that fixes things, I'd leave it off. Embedded Perl isn't actually all that much of a win. Thanks for the suggestion; I'll give that a try. The problem is intermittent enough that it may be a couple of weeks before I see if that change helps or not. As an RFE/bug report, can mimedefang-multiplexor be modified to keep failed working directory under more circumstances? Can and should mimedefang-multiplexor be modified to not close file descriptors on forking? Thanks. Josh Kelley ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] File descriptors and error handling
While trying to track down a problem on my mail server, I found a couple of questions/problems regarding MIMEDefang: First, a problem with MIMEDefang's error handling: I'm getting some errors "Unknown command '...' in RESULTS file" and "RESULTS file did not finish with 'F' line" in my syslogs. It looks like MIMEDefang deletes working directories after this error occurs, even if KEEP_FAILED_DIRECTORIES is set. MIMEDefang should probably keep the working directory for "RESULTS file did not finish with 'F' line", "Overlong line in RESULTS file", and possibly "Failure in cleanup" and "Unknown command '%c' in RESULTS file." Second, I'm apparently having problems with my file descriptors getting mixed up in MIMEDefang. Binary data of an unknown origin is being written to RESULTS, nss_ldap's getpwnam lookups are trying to read from a PTY that's opened for one of my mimedefang-filter's child processes, and output intended for that child process is showing up in syslog. The problem seems very intermittent and only (or primarily) seems to happen if nscd isn't running. I'm wondering if some of the problem is caused by mimedefang-multiplexor's closing all open file descriptors after forking. As part of its initialization on my system, it makes some nss calls, which results in nss_ldap opening and leaving open an LDAP connection; I'm guessing that nss_ldap is then running into trouble (such as trying to read from a child's PTY or, perhaps, writing binary data to RESULTS) after a fork because it's trying to use this connection that it thought was still open. I ran into similar problems before with syslog trying to hold a file descriptor open (fixed in MIMEDefang 2.42). I'm starting to wonder if it would be better if mimedefang-multiplexor not close file descriptors on a fork, to avoid problems like this, since I don't see any good way for it to know what FDs SpamAssassin, nss libraries, and so on have opened. Any other ideas on how to track this problem down? Thanks. Josh Kelley ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] SpamAssassin from MIMEDefang vs. spamd
On 6/14/06, Fredrik Nyberg <[EMAIL PROTECTED]> wrote: running spam_assassin_check() on mail produces different results than dumping said to spamd; very different results indeed. Configs seem to be loading correctly and local.cf has been loaded. Sometime bayes test seem to differ, too. MIMEDefang always runs SpamAssassin checks as the defang user (or whatever user you configured mimedefang to run under). This means that you only use defang's Bayesian database and don't use per-user SpamAssassin configurations. spamd uses separate Bayesian databases and checks for separate SpamAssassin configurations for each recipient. MIMEDefang also loads its own sa-mimedefang.cf file by default; that may affect its configuration. Josh Kelley ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] sa-update
On 4/24/06, David F. Skoll <[EMAIL PROTECTED]> wrote: > Jonas Eckerman wrote: > > > +my $LOCAL_STATE_DIR = '/var/lib'; > > That works for FreeBSD, but look at Mail-SpamAssassin's Makefile.PL. > It contains a subroutine "_set_macro_LOCALSTATEDIR" that supposedly > sets the default for LOCAL_STATE_DIR. If anyone doesn't think > SpamAssassin is an evil piece of code, _set_macro_LOCALSTATEDIR should > remove all remaining doubts. > > If/when I find a general-purpose way to detect what the [EMAIL PROTECTED]&$&#$ > LOCAL_STATE_DIR should be set to for a given SpamAssassin installation, > I will patch MIMEDefang to use it. If I can't figure it out, I'll > just use /var/lib. sa-update knows what LOCAL_STATE_DIR is, and sa-update is simply Perl code, so how about just taking its setting of LOCAL_STATE_DIR and eval'ing it? my $LOCAL_STATE_DIR; my $setlocalstatedir = `grep '^my \$LOCAL_STATE_DIR' /usr/bin/sa-update`; $setlocalstatedir =~ s/^my //; # Remove leading "my" so that $LOCAL_STATE_DIR isn't scoped locally to eval block eval $setlocalstatedir; Or is that too much of a hack? Josh Kelley ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] MUA tracking?
On 3/9/06, Philip Prindeville <[EMAIL PROTECTED]> wrote: > Are you interested in just what your users are using, or what is still > out there? > > If the former only, then you'll want to either just look at stuff > coming in that's authenticated, or coming in on your submission port, > or else coming from your internal networks... Or on messages that > have no Received: lines... Just what our users are using. I was already planning on doing something like what you suggested (although I really hadn't figured any details yet - thanks for the suggestions). Josh Kelley ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] MUA tracking?
I'm interested in gathering statistics on which MUAs our users use (so we can find out what mail clients are popular enough to officially support, which old clients we can drop support for, who's using old versions and should be gently encouraged to upgrade, etc.). I figure that MIMEDefang can track this by grabbing the X-Mailer: header of messages as they go through, and I thought that I'd ask the list to see if anyone's already done this before I go write some code. Alternatively, would there be a better way of doing this? Josh Kelley ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Mimedefang and clamd configuration problems - SOLVED
On 12/28/05, David F. Skoll <[EMAIL PROTECTED]> wrote: > In the RPM case, you need to explicitly set the appropriate %Features member > in your filter. > > I should document this better in the man page (and on the Wiki.) I'd also suggest documenting it in the sample filter. Josh Kelley ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] FTC asks ISPs to crack down on zombie PCs
James Ebright wrote: On Thu, 26 May 2005 15:20:33 -0400, WBrown wrote Ummm wouldn't TLS only encrypt the traffic between the two servers involved at the moment, ie, your mail server and theirs as you relay though it? Encrypting the contents of the message would keep it out of their hands. It encrypts the transmission of the message(s) from MUA through to Final Delivery MTA Assuming every MTA in the middle can handle TLS, once a non TLS MTA is hit from there on it is regular ole plaint text. Sorry, I don't think this is correct: My MUA doesn't know the final delivery MTA, so it can't encrypt a message for viewing by the final delivery MTA only. Instead, it uses TLS to encrypt the entire SMTP conversation with my local MTA. My local MTA then takes the plaintext message and passes it on to the next MTA in the delivery chain. If the next MTA supports TLS, then the message is re-encrypted, passed across the wire as part of an encrypted SMTP conversation, and again decrypted by the next MTA. And so on to the final location. TLS encrypts traffic across the wire, but each MTA in the chain sees the message. Like WBrown said, if you don't want ISPs reading your mail, encrypt the messages, don't rely on TLS. This is at least my understanding. If I'm missing something, please let me know. Josh Kelley ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Virus scanning: ignore text/plain and text/html?
Matt Cuttitta wrote: It makes perfect sense to me to skip over the text/plain and text/html parts as I'm not sure how they could contain viruses. However, I haven't seen or heard of anyone else doing this. Anyone else looked into this? Comments? In addition to others' comments, virus scanners like ClamAV and (I think) uvscan can catch some phishing scams. Josh Kelley ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] HUGE problem with mimedefang
Kenneth Porter wrote: Both Fedora and RH should use an RPM approach, which means finding all the prereqs. You can either install all the Perl prereqs using CPAN and then --nodeps (not --force) the MD RPM, or download and repackage them as RPM's with cpanflute2 (part of RPM::Specfile). (I recall having trouble with a package or two because cpanflute2 expects a certain naming convention that they don't follow.) Dag's RPM repository (http://dag.wieers.com/home-made/apt/) offers all of the necessary Perl prereqs prepackaged as RPMs. I've been using those for a while and have been quite happy. He also provides a Mimedefang RPM; it's out of date at the moment, but generally all it takes to get an update is an email and a one or two day wait... Josh Kelley ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] HUGE problem with mimedefang
Sven Schuster wrote: The only other thing which was a pain in the a** were the modules included in the perl rpm packages, which made it quite hard to update them without running into problems with rpm (giving collisions with the perl package when trying to rpm -Uvh for example Digest::MD5). But I made my own perl spec where things like Digest, Digest::MD5, and some others resulted as separate rpms, thus making it easy to upgrade those modules via rpm. Would you mind posting your perl specfile (or emailing it privately)? I just built MIME-Base64 as a regular RPM then did a force install over top of the perl package, but that approach has obvious disadvantages. Josh Kelley ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Compliance
alan premselaar wrote:
I'd be interested in at least looking at it. Currently I'm using
procmail for local delivery and its Quota handling is kludgey at best.
I'd really like to get something working within MD. Since the method
Jan uses calls the perl module for Quota directly, I don't think
setting setuid on the quota application will make any difference
(although I haven't looked at the Quota module code either)
Here you go. A brief explanation: we're only really interested in
checking quotas for students, since faculty/staff don't have quotas.
Students use their student IDs for their usernames, with
firstname.lastname set up as an email alias, so we have to check
aliases. We test for numeric usernames to see if the account is a
student (instead of testing something sensible like the account's gid -
I don't know what I was thinking). Rather than checking current space
usage against the message size, as Jan did, we just check to see if the
user has already exceeded their soft quota and has exceeded their grace
period (i.e., grace is 'none'). This means that the occasional
over-the-quota bounce still gets generated (for messages that exceed the
hard limit before the grace period expires, or for messages so big that
they exceed the hard limit for users currently below the soft limit).
This hasn't usually been a problem, but sometime I'll go back and add
Jan's enhancements - thanks, Jan, for posting your code.
sub filter_initialize() {
$quota_dev = Quota::getqcarg('/var/spool/mail');
tie(%alias, 'DB_File', '/etc/aliases.db', O_RDONLY, 0);
}
sub filter_recipient($) {
my ($recipient, $sender, $hostip, $hostname, $first, $helo,
$rcpt_mailer, $rcpt_host, $rcpt_addr) = @_;
# For local students, check quota
if ($rcpt_mailer eq 'local') {
my($real_addr) = lc($rcpt_addr);
# Chase down any aliases
while ($alias{$real_addr . "\0"}) {
$real_addr = $alias{$real_addr . "\0"};
$real_addr =~ s/\0$//;
}
# Only check students who don't forward mail.
($real_addr =~ /^\d+$/) or return ('CONTINUE', 'ok');
my($uid, $homedir) = (getpwnam($real_addr))[2,7];
(-f "$homedir/.forward") and return ('CONTINUE', 'ok');
# Check the quota. We have to query by UID, since numeric
# usernames confuse the quota binary.
my($quota) = grep { /^\s+$quota_dev/ } split(/\n/,
`/usr/local/bin/wwwquota $uid`);
if ($quota =~ /\*.*none/) {
return ('TEMPFAIL',
"$recipient... User mailbox is full, cannot deliver",
'452', '4.2.2');
}
}
return ('CONTINUE', 'ok');
}
Hope this helps.
Josh Kelley
___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Compliance
Alan Premselaar wrote: On what system do you have this implemented? (linux? kernel?) I'm playing around with an implementation on RedHat ES 3.0 and the problem I'm running into is that MIMEDefang runs as the defang user, Quota::query is only allowed to get quota information for other users if run as the superuser. did you run into these kind of issues? do you have a work around? We use a setuid copy of /usr/bin/quota to do quota checking on our Red Hat server. (We use a copy rather than making /usr/bin/quota setuid since any updates to the quota package would reset the setuid bit.) It's probably not the most efficient setup, but I thought that it would be simpler than a quota daemon. I can post my code if anyone's interested, although it's not as fancy as Jan's. For example, we don't do any checking on ESMTP SIZE=, we just bounce for people who have exceeded their quota and exceeded their grace period. Josh Kelley ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] for mcafee lovers
Joseph Brennan wrote: --On Tuesday, March 22, 2005 14:29 -0500 "Kevin A. McGrail" <[EMAIL PROTECTED]> wrote: Since defang is a single user, you just need 1 license but 5 is the minimum to purchase. I never tried this one with vendors! They accept this? The consensus seems to be that McAfee at least does. See the following: http://www.peregrinehw.com/downloads/MIMEDefang/INSTALL-MCAFEE http://lists.roaringpenguin.com/pipermail/mimedefang/2003-September/017203.html http://groups-beta.google.com/group/comp.mail.sendmail/browse_frm/thread/e9d0369b0c3a2bcd/86b7f1754f6c5de4 FWIW, our sales rep gave the same answer - one server or username (don't remember which) running MIMEDefang, so one license. Josh Kelley ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] for mcafee lovers
Damrose, Mark wrote: I run Clam on MD acting as a relay to an Exchange server running McAfee. Before I upgraded to a version of Clam that would catch phishing e-mails, the McAfee would regularly catch them. There is still an occasional one that McAfee catches that slipped past Clam. I have no clue if the Unix version catches them. I checked; the Unix version does catch phishing. We also used to use it to catch phishing before ClamAV updated. Josh Kelley ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Which Virus Scanner?
Jonathan Maliepaard wrote: I know this is good ;-) But I am not convinced that McAfee is being used. My CPU's are so fast, I never see Uvscan appear in "top" Is there a way to work out if it is being used (like increasing a log level?) Assuming you haven't mounted your disks with the noatime option, you can check the access time on the uvscan binary to see if it's being called: ls -l --time=access /path/to/uvscan Josh Kelley ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] MIMEDefang/SA and SURBLS
Mike Carlson wrote: I didnt get a URIBL score at all. Check that you've installed a recent enough version of Net::DNS. For example, version 0.31, which ships with RHEL 3, is too old. SURBL checks will silently fail if Net::DNS is out of date. Josh Kelley ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Warning: unable to close filehandle LOGF properly.
Tory Blue wrote: Did a search and a few people see this but no answers. Did I miss something running Mime 2.44/clamav/sendmail 8.13 on a Linux box mimedefang-multiplexor[15477]: Slave 1 stderr: Warning: unable to close filehandle LOGF properly. I think that it's related to this problem and the related bugfix: http://lists.roaringpenguin.com/pipermail/mimedefang/2004-March/021318.html Mimedefang makes certain that it closes the filehandle used to talk to syslog, and I think that it occasionally closes it even when the filehandle isn't open, which prompts this warning. I first noticed messages similar to this after adding the bugfix listed above, so I'm pretty sure they're related. The warnings should be harmless, so I've just ignored them. Josh Kelley ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] curly brackets - security risk?
Chris Masters wrote:
I know the default extension regex does not allow open
curly brackets ('{'). I assume this is a security
feature.
What about filenames? I know they're legal in both
unix and windoze, but do they pose a security risk?
Windows lets you put a classid (hexadecimal string identifying the file
type) in curly brackets and use that as a file extension. At least one
virus has used this technique to hide its extension.
See http://www.geocities.com/uzipaz/eng/safe.html, item 8, for more details.
Josh Kelley
___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
[EMAIL PROTECTED]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] How to determine if SendMail is configured with MILTER support...
Kevin A. McGrail wrote: Suggest you use RPM with RHES. Download the latest source RPM (last I did this in November, it was sendmail-8.12.10-1.src.rpm ) Run rpmbuild --rebuild sendmail-8.12.10-1.src.rpm Then you will have a sendmail-devel RPM in /usr/src/redhat/RPMS/i386 This will give you the MILTER support from the RPM. Also note that the most recent updates to RHEL 3 include a sendmail-devel RPM, so if that's all that you're lacking, you don't even need to rebuild the source RPM. Josh Kelley ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Poll: Time to drop Trophie support?
Jerome Tytgat wrote: One point I prefer Sophie/Sophos vs Clamav is because I can get a newsletter from Sophos indicating new release of IDE (viral signatures). I've set up a procmail catch up which download new IDE as they are released. So I think I'm more uptodate with Sophie/Sophos than with Clamav. ClamAV offers an email list of virus signature updates as well: http://lists.sourceforge.net/lists/listinfo/clamav-virusdb It's been my experience that ClamAV updates their signatures VERY fast; much faster than McAfee (the only other antivirus program that I have much experience with). Bugtraq indicates that they've been faster than Sophos too: http://www.securityfocus.com/archive/1/353379/2004-02-07/2004-02-13/0 I'd recommend that you give ClamAV a try; as others on the list have pointed out, you can set up MIMEDefang to use both virus scanners for a while, so you can test out ClamAV and make sure that it isn't letting anything through to Sophie. Josh Kelley ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Mimedefang not calling virus scanners sometimes
Bill Maidment wrote: Because File-Scan identifies the NetSky virus and variants with that name and ClamAV identifies the same viruses as SomeFool, I would have expected the first virus scanner (which happens to be File-Scan) to always pick them up give them all the same name (NetSky in this case). However the logs show a mix of NetSky and SomeFool names (see attached graphdefang image), which leads me to the conclusion that for some reason File-Scan is not picking up the virus first and so it is caught by ClamAV. That's not so bad, but yesterday we had an older virus (Welchia-B) get through both File-Scan and ClamAV, even though it was known to both. I haven't used File::Scan, but from using NAI uvscan and ClamAV, I've noticed some differences in how virus scanners handle bounced messages, error messages, etc. A bounce or error message may contain a virus, part of a virus, or remnants of a virus after an ignorant virus scanner removed it. Because there are so many different variations on how these emails may appear, and because some of these emails aren't properly formatted, I suspect that no virus scanner can properly handle them all. I've seen ClamAV (very rarely) miss a virus that NAI uvscan catches, and I've seen uvscan may miss a virus that McAfee VirusScan for Windows (also an NAI product) catches. I would guess that this is what's causing you to see a few viruses slip through. Josh Kelley ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] command line notification of failure of mimedefang or similar
Lucas Albers wrote: I am currently using swatch to monitor my mail log for clamd errors. If mimedefang or clamd stop working I cannot email notify anyone. Does anyone use a command-line mailer/script to connect directly to another mail server in this situation? For cases in which the local mail server is not functioning? I haven't used it, but it sounds like nullmailer should do what you're asking: http://untroubled.org/nullmailer/ We've had good results using sendpage to page us via modem if email goes down: http://sendpage.cpoint.net/ Josh Kelley ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Embedded Perl problems - bugfix
I think that I've found and fixed a problem in MIMEDefang's embedded Perl mode. The problem: The MIMEDefang multiplexor uses the openlog and syslog functions to write to the syslog. These functions use a file descriptor kept in a static variable somewhere to do the actual writing. However, when the multiplexor forks off a child, the child closes all open FDs. If the Perl filter then opens a file, it may happen to get the same FD that the openlog/syslog functions expect to use. Bad things ensue. (On my system, the FD conflict was causing slave processes to hang.) Solution: Add a closelog() call to mimedefang-multiplexor.c's activateSlave function, just before "Close unneeded file descriptors" loop. Josh Kelley ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Embedded Perl problems
Lucas Albers wrote: You should show this sort of command arguments when you run ps axuww|grep mimedefang /usr/bin/mimedefang-multiplexor -p /var/spool/MIMEDefang/mimedefang-multiplexor.pid -E -m 4 -x 9 -U defang -i 30 -b 600 -W 1 -l -q 10 -s /var/spool/MIMEDefang/mimedefang-multiplexor.sock Notice the -E. Verify that it had embedded support when it was compiled. I've verified that the -E is listed in the ps auxwww listing, and I've verified that embedded support was compiled in. Any other suggestions? Josh Kelley ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Embedded Perl problems
Lucas Albers wrote: What version of perl are you running? 5.8.0, the version that ships with RHEL 3. Look at the shared memory, it will indicate that each slave is sharing 2/3 of it's memory with the master. Like such: defang 9 0 31992 31M 19972 S 0.0 6.3 0:00 mimedefang-mult defang 9 0 31040 30M 20600 S 0.0 6.1 0:00 mimedefang-mult defang 9 0 30220 29M 29740 S 0.0 5.9 0:00 mimedefang-mult defang 9 0 30212 29M 29732 S 0.0 5.9 0:09 mimedefang-mult defang 9 0 1632 1628 1408 S 0.0 0.3 0:00 mimedefang defang 4 0 1632 1628 1408 S 0.0 0.3 0:00 mimedefang defang 9 0 1632 1628 1408 S 0.0 0.3 0:00 mimedefang defang 9 0 1632 1628 1408 S 0.0 0.3 0:00 mimedefang See the number after 31m that is 20m or so? You can see te 3rd and 4th slave aren't using any extra memory, they are sharing all from the parent. That's what I was looking at. The 5th column for the mimedefang-multiplexors was only 3m or so, the same as it is when I have embedded Perl disabled. You need to specifically enable the embedded option with the -E switch on the multiplexor startup script. I'm using the provided init script for Red Hat, so I can set the appropriate option in /etc/sysconfig/mimedefang to make the init script pass the -E option. I've confirmed that ps lists the children as "mimedefang-multiplexor" rather than "perl mimedefang.pl", which should mean that embedded Perl is enabled. Josh Kelley ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Embedded Perl problems
I'm trying to get the multiplexor's embedded Perl mode to work, since messages on the mailing list indicated that it would save a lot of memory, and our mail server (running Red Hat Enterprise Linux 3) is a bit limited on memory. First, a minor point: it doesn't seem to be helping the memory usage any. I'd read on the list that embedded Perl mode should cause the "shared" column of top to be much higher, but it seems to be about the same as in non-embedded mode. Second, a major point: when I enable embedded mode, slaves apparently tend to become busy and never report that they're done. Slaves will still sometimes work, so some mail goes through - I haven't been able to figure out why things sometimes work and sometimes don't. Eventually, though, all of the slaves become busy, up to MX_MAXIMUM. Any idea what might be causing this? Any suggestions on how I could track down the problem? Thanks. Josh Kelley ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] perl runtime flags
Chris Masters wrote: Hi All, I'm trying to debug some of my filter code and I'm getting a lot of warnings to stderr that are redirected to syslog - which is fine. The main errors I'm getting are to do with bitwise operators and byte arrays. I can't reproduce these errors when running the same code outside of MIMEDefang. So, what warning flags is MIMEDefang run with (looks like it's just -w in the process list)? We're running with non-embedded mode. The -w flag to Perl enables the warnings that you're seeing. You can add " -w" to the "#!/usr/bin/perl" line of your test stub to have your test stub print the same errors, or you can add "use warnings;" to the beginning of your code to have the same effect. The "ugly hack" way to get rid of these messages is to add "no warnings;" to your mimedefang-filter to disable the warning messages. Your use of IO::Socket::INET that you quoted looks okay, so I wouldn't think that the warnings are coming from there; I'd guess that they might be coming from wherever you initialize your socket. But I'm not very familiar with IO::Socket::INET, and without seeing your code or the exact warnings, I'm just guessing. Hope this helps. Josh Kelley ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] MIMEDefang 2.40 is released
Stephen Smoogen wrote: On Fri, 2004-03-05 at 12:37, Josh Kelley wrote: 1. Most mass-mailing viruses are sent directly by the virus, in which case no one will see any bounces generated. Right and Wrong. Most mass mailing viruses are sent by the virus, but with a spoofed email address that can be either something in the mailbox or some other item. I get about 20 you sent this virus that I couldnt have sent every week. I'm not suggesting sending out "you sent this message" notifications; I know that's a bad idea. I'm suggesting using action_bounce, which rejects the message at the SMTP level, instead of action_discard, which accepts the message and silently discards it. In this case, the only time someone would see the bounce is if the virus sends a copy of itself through unprotected mail server A, unprotected mail server A tries to relay the message to protected mail server B, which rejects the message, so then unprotected mail server A tries to generate an error message to the forged sender address. The proper fix for this problem, I think, is for mail server A to add virus protection, not for mail server B to start silently discarding email that it can't guarantee has no valid content. 2. Bounces will be generated anyway, if a mass-mailed virus is sent to an invalid email address, so avoiding action_bounce won't stop bounced viruses. If it isnt sent.. then it wont create anything. The discard kills the SMTP session. If the virus sends a copy of itself through unprotected mail server A, and unprotected mail server A tries to relay the message to an invalid email address on mail server B, then mail server B will reject the message regardless of how it handles viruses, and then unprotected mail server A still tries to generate an error message to the forged sender address. So viral bounces can still get generated whether the mail server bounces or discards viruses. 3. If the the virus is, for example, a Word macro virus, it shouldn't be silently dropped. Eh? I dont know if that is correct either. You still have to assume that you are sending the bounce to the correct person. If people could/do put in such conditional rules (if binary-virus->kill else if word->bounce then the spam/child-porn/mafia/anyone-else-making-money-of-viruses would just then use that as a new novel way to get mass mailings done. [Send bad email with porn/spam/etc with word-macro-virus and have the forged sender be the person you want to send the spam to in the first place.. bang you are assured that person will get tons of your spam because people are going to bounce it to the recipient.] My argument is that if a mail server silently drop all viral messages, it risks losing valid content. I don't know of a good way to prevent this. Your argument is that if a mail server bounces viral messages, then it can conceivably used to spam people. This can be prevented by adding virus protection to mail servers and by various anti-spam methods currently available. 4. To summarize, in the man page's words, "It's almost never a good idea to hide a problem." No it isnt.. but it doesnt really not hide the problem. Most of these viruses I see here have already been sent through 1-2 mail-relays and the original host/sender is impossible to track down. I cant tell who sent the virus so I cant tell them to clean their machine. Me sending back a bounce that goes to an innocent 3rd party who didnt send the email just makes the problem worse.. as they have no idea why they are getting this email. Most of the viruses that I get at my mail server come directly from infected computers, if I'm reading my mail server logs correctly. I'm not particularly interested in tracking down the original sender of the virus. I am interested in letting someone know that their email was rejected if they try to email a viral message. Again, I'd like to know why the recommendation in MIMEDefang 2.40 was changed from action_bounce to action_discard. Josh Kelley ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] MIMEDefang 2.40 is released
David F. Skoll wrote: On Fri, 5 Mar 2004, Josh Kelley wrote: he mimedefang-filter manpage still recommends using action_bounce rather than action_discard. Is action_bounce no longer recommended? Right. I should fix the man page. I'm sure that this topic has come up many times on the list before, and I'm sorry for bringing it up again, but the last time I remember seeing it discussed here, I thought that the general consensus was that bounce was better, for roughly the following reasons: 1. Most mass-mailing viruses are sent directly by the virus, in which case no one will see any bounces generated. 2. Bounces will be generated anyway, if a mass-mailed virus is sent to an invalid email address, so avoiding action_bounce won't stop bounced viruses. 3. If the the virus is, for example, a Word macro virus, it shouldn't be silently dropped. 4. To summarize, in the man page's words, "It's almost never a good idea to hide a problem." Why the change in recommendation? Again, sorry for rehashing old material. Josh Kelley ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] MIMEDefang 2.40 is released
David F. Skoll wrote: * Default action for viruses (in the sample filter) is now discard. The mimedefang-filter manpage still recommends using action_bounce rather than action_discard. Is action_bounce no longer recommended? Josh Kelley ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] action_quarantine_entire_message
Dirk Mueller wrote: On Saturday 28 February 2004 21:48, Dirk Mueller wrote: Quarantines the entire message in a quarantine directory on the mail server, but does not otherwise affect disposition of the message. If "$msg" is non-empty, it is included in any administrator notification. To my surprise, it seems that action_quarantine_entire_message's parameter, $msg, is added inline to the actual message. That was... ehh, quite surprising, since the messages were politically incorrect debug messages, and which confused the hell out of the actual recipient, since they suddenly appeared in the middle of a legitimate, nonspam, nonvirus email. Could anyone confirm that this is a bug in mimedefang ? I believe that I can confirm. I haven't had anyone complain, but I've seen messages bounced for other reasons that have had the quarantine notifications added inline, when that's not at all what I would expect. Josh Kelley ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] [OT] SBL
I realize this is a bit OT, but I've seen SBL recommended here before, and I'm not sure where else to ask... I'm trying to reconfigure our mail server to start blocking spam instead of tagging it with SpamAssassin and trusting our users to set up their own filters based on SpamAssassin. Blocking messages based on the SBL seemed like a good first step. In the week or so since I've started using the SBL, it's caught about half of the incoming mail to our campus, but it's also caused 4-5 false positives (a spammer's company that happens to put out a good newsletter, legitimate mailing lists hosted by spammers, a legitimate company that uses a spam-friendly ISP as their hosting provider). This surprised me, since I was under the impression that the SBL was probably the most trusted and most conservative of the blacklists. Should I give up on blocking via the SBL? Or should I just accept that if I'm going to block mail, I'm going to block a few legitimate ones by mistake? I know that others on this list use the SBL - have you had any similar problems? Thanks. Josh Kelley ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Solaris And Syslog issues.
David F. Skoll wrote: However, sending INT to the multiplexor to reread the filter is deprecated. Instead, you should use: md-mx-ctrl reread The Red Hat init script in redhat/mimedefang-init still uses kill -INT and so should probably be updated. Josh Kelley ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
