Re: [Mimedefang] ClamAV's Worm/Trojan/Joke/W97M classifications
Kelson wrote: [EMAIL PROTECTED] wrote: My address would have to be forged by a virus that uses a relay, and most of the current viruses are direct to MX with their own SMTP engines. In these cases this is moot. The message just dies with 550. Expect this to change as more ISPs start filtering outgoing SMTP connections. All a virus (or spam zombie) has to do is extract the settings from the user's mail config and send via the ISP's relay. Depending on how the app stores the password, it may even be possible to use SMTP AUTH. One of the reasons I use 550 rejects for viruses is that I also scan outgoing mail... so if by some chance one of my users gets infected with a virus (regardless of the fact that we have desktop antivirus software installed on all our machines as well as ClamAV on the MX server) and it tries to send out using our mail gateway, the mail gateway will reject that mail with a 550 and throw an error back to the client machine. if the virus is in an attachment that they're legitimately trying to send, they'll get an error message and then they'll undoubtedly come crying to the helpdesk which will then kick them and tell them to run the latest antivirus software/signatures. if we just dumped viruses into /dev/null, the user would assume their mail was sent and just "never got to the recipient" ... considering that a lot of our business is conducted via email (internationally) and can often be time sensitive... by the time we figured out that the intended recipient never received the mail (at this point probably x times), and why, it may be too late. there are pros and cons to both solutions. choosing the solution in which the pros outweigh the cons for your situation is the important part. alan ___ 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] MD on a fresh machine
On Thu, Jun 30, 2005 at 11:15:01AM -0400, Dirk the Daring wrote:
>After installing SA, I used this script to check the installation
> status of all the modules:
>
> #!/opt/perl/bin/perl
>
> use ExtUtils::Installed;
> my $instmod = ExtUtils::Installed->new();
> foreach my $module ($instmod->modules()) {
> my $version = $instmod->version($module) || "???"
> print "$module -- $version\n";
> }
>
>This was the result when I ran the script:
>
> [EMAIL PROTECTED] /home/admin 5 % perl listmods.pl
> Archive::Zip -- 1.14
> Compress::Zlib -- 1.34
> DB_File -- 1.811
> Digest::HMAC -- 1.01
> Digest::SHA1 -- 2.00
> HTML::Parser -- 3.45
> HTML::Tagset -- 3.04
> IO::Stringy -- 2.110
> MIME-tools -- ???
> MIME::Base64 -- 3.05
> Mail -- ???
> Mail::Audit -- 2.1
> Mail::SpamAssassin -- 3.04
> Net -- ???
> Net::DNS -- 0.51
> Net::IP -- 1.23
> Perl -- 5.8.6
> Pod -- ???
> Time::HiRes -- 1.66
> Unix::Syslog -- 0.100
>
>I'm concerned that the MIME-tools, Mailtools, Net and Pod modules do
> not show up as having a version. These are what I installed:
This is a bug or anomaly in the ExtUtils::Installed module - it has
nothing to do with your system. "Mail", "Net", and "Pod" are not
modules, they are module hierarchy roots. No idea why they show up.
"MIME-tools" is just the name of the distribution, the actual modules
have names starting with MIME::
So you can just ignore this.
--
#!perl -wpl # mmfppfmpmmpp mmpffm <[EMAIL PROTECTED]>
$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
___
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] Odd nonset variable issue
Thanks for the reply Jan.
It's happening in filter_begin. I'll evaluated again
after we've upgraded to the latest MIMEDefang to see
if it's still a problem and report back.
Chris
--- Jan Pieter Cornet <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 30, 2005 at 06:14:09AM -0700, Chris
> Masters wrote:
> > Just to clarify; the variables were set as
> specified
> > below rather than with the envelop
> sender/recipient
> > and the sendmail allocated qid.
> >
> > This happened with:
> >
> > mimedefang-2.43
> > sendmail-8.13.0
>
> You aren't accidentally testing variables that were
> set _from_
> $QueueID and $Sender and the like, in the
> filter_recipient routine,
> only to find out that those other variables are
> "miraculously" empty
> at filter_end time? Because that is easy to explain
> (using the
> "GLOBAL VARIABLE LIFETIME" section in the
> mimedefang-filter manpage).
>
> If you aren't, then I can only speculate that it's a
> sendmail 8.13.0
> bug. You might try upgrading to 8.13.4. Your
> mimedefang version is also
> fairly old, but I know 2.43 is pretty stable, we
> used it for about a year
> I think.
>
> --
> #!perl -wpl # mmfppfmpmmpp mmpffm
> <[EMAIL PROTECTED]>
>
$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
> ___
> Visit http://www.mimedefang.org and
> http://www.roaringpenguin.com
> MIMEDefang mailing list
> MIMEDefang@lists.roaringpenguin.com
>
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
>
Yahoo! Sports
Rekindle the Rivalries. Sign up for Fantasy Football
http://football.fantasysports.yahoo.com
___
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] ClamAV's Worm/Trojan/Joke/W97M classifications
Alan wrote: > One of the reasons I use 550 rejects for viruses is that I also scan > outgoing mail... so if by some chance one of my users gets infected with > a virus (regardless of the fact that we have desktop antivirus software > installed on all our machines as well as ClamAV on the MX server) and it > tries to send out using our mail gateway, the mail gateway will reject > that mail with a 550 and throw an error back to the client machine. > > if the virus is in an attachment that they're legitimately trying to > send, they'll get an error message and then they'll undoubtedly come > crying to the helpdesk which will then kick them and tell them to run > the latest antivirus software/signatures. > While it certainly makes sense to reject viruses when scanning outgoing mail from your own network, it's best to make sure that virus attachment is removed prior to rejecting and generating the bounce. We also used to do the same thing (rejecting viruses) when it came to outbound mail from our own mail server (which is completely separate from our MD/ClamAV (CanIt-PRO) gateway cluster), where we run a commercial AV scanner. In at least a dozen or so situations early last year, we were basically rejecting viruses from client PCs, but the ignorant users (who WERE NOT infected prior to receiving the bounce), would open the attachments in the bounce and infect their PCs, spreading the virus like wild fire. Let me explain... So, [EMAIL PROTECTED] would be infected (where a virus, such as W32.Bagle, would be auto-generating email from their PC and sending out copies of itself), sending out the virus using a forged FROM address from [EMAIL PROTECTED], and our mail server would reject and generate a bounce to user-y, containing the virus attachment in the NDN. This raised hell for us. After spending all-nighters several days in a row getting rid of the virus last year, we changed the policy on our mail server so that viruses were removed, so that the reject only contained the 5xx code and headers, hoping that we could, perhaps, trace the source based on the NDN -- not the case. Recent viruses make our lives even more difficult because they fake the source IP, so now we can't even trace the thing back to the infected PC, at least not via the NDN. We have to rely on logging to trace viruses. You could easily argue my position by stating "well, if you reject at the SMTP connection phase, the client PC sending the virus receives the rejection no matter what". Ok, that's true, but the NDN/reject still confuses the user, but yes, it does help to narrow down where the virus is coming from, but logging is even easier and wastes less of our time. So, now we discard outbound viruses sent from users on our own network, and rely solely on our virus logging utilities to figure out where the virus originated from. We have found that rejections are absolutely USELESS to end users, they don't understand them and it just generates unnecessary and wasteful helpdesk calls. When you're trying to maximize and use your IT staff's time most efficiently, discarding viruses is the ONLY resolution that makes sense; and I imagine this scenario applies to a majority, and not just a few of you. - Chris -- Chris Gauch Systems Administrator Digicon Communications, Inc. http://www.digiconcommunications.com [EMAIL PROTECTED] ___ 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] ClamAV's Worm/Trojan/Joke/W97M classifications
On Thu, 30 Jun 2005, Matthew Schumacher wrote: > Les and the others make valid points. Rejecting the message will still > cause some other relay to generate a bounce message, that is a > disadvantage of rejecting vs dropping. I think "'may' cause some other relay..." would be more accurate. Jim McCullars University of Alabama in Huntsville ___ 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] ClamAV's Worm/Trojan/Joke/W97M classifications
On Thu, 30 Jun 2005, Les Mikesell wrote: > No, this is the other side of the same SMTP conversation. I'm asking > you to consider what a rejection sets in motion. Because I am scanning at the MX for my domain, and because the vast majority of these viruses come from a hijacked PC with its own SMTP engine that don't do returns, I think that most of them end there. > There really is no question about what you have to do with a negative > DSN from the next MTA. Likewise they have no choice about what to > do when you issue one. Again, you are assuming that these virus programs perform to standards. I think this is an erroneous assumption. Jim McCullars University of Alabama in Huntsville ___ 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] ClamAV's Worm/Trojan/Joke/W97M classifications
Chris Gauch wrote: Alan wrote: One of the reasons I use 550 rejects for viruses is that I also scan outgoing mail... so if by some chance one of my users gets infected with a virus (regardless of the fact that we have desktop antivirus software installed on all our machines as well as ClamAV on the MX server) and it tries to send out using our mail gateway, the mail gateway will reject that mail with a 550 and throw an error back to the client machine. if the virus is in an attachment that they're legitimately trying to send, they'll get an error message and then they'll undoubtedly come crying to the helpdesk which will then kick them and tell them to run the latest antivirus software/signatures. While it certainly makes sense to reject viruses when scanning outgoing mail from your own network, it's best to make sure that virus attachment is removed prior to rejecting and generating the bounce. We also used to do the same thing (rejecting viruses) when it came to outbound mail from our own mail server (which is completely separate from our MD/ClamAV (CanIt-PRO) gateway cluster), where we run a commercial AV scanner. In at least a dozen or so situations early last year, we were basically rejecting viruses from client PCs, but the ignorant users (who WERE NOT infected prior to receiving the bounce), would open the attachments in the bounce and infect their PCs, spreading the virus like wild fire. Let me explain... I'm not generating bounces... i'm merely 550 rejecting ... which is fine in my situation because it's the SMTP outgoing gateway machine that is rejecting the contect coming directly from the client machine. (which is on our local network) ... so, what happens is, the user (on said client machine) writes email, attaches a file, hits send, gets a popup windows that says "ERROR 550 YOUR MESSAGE CONTAINS A VIRUS" and doesn't go beyond that point until they either a) figure it out themselves and run their anti-virus scanner or (more likely) b) contact our helpdesk and admit that they don't know enough to really be allowed to touch a computer even indirectly connected to the internet. then our help desk eraddicates the virus or tells the user they're SOL. no bounces (aka DSN or NDN) involved. we have instituted a no MS internet software policy, but it doesn't necessarily mean that someone's not going to open OE or IE out of habit or just cuz they think they know what they're doing. Also, one point that has been glazed over in this entire thread is that email is not the only way for these machines to be infected with viruses, and the user doesn't even have to be a complete moron to become infected any longer. Especially with exploits in which all you have to do is open the wrong URL, without knowing it or any indication on the site itself, just that one little act can infect your machine. nothing to do with mail. right or wrong, i don't think either solution really adds any more to the problem, nor does it really remove anything from the problem. I think what these solutions do is change the way the problem is perceived by the people that are directly affected by the implementation of these solutions. if AV scanners were absolutely, without a doubt 100% reliable, that would be a different story. if there were NO OTHER WAYS to contract these viruses, it would be a different story. if there weren't other legitimate causes for DSNs, NDN, or whathave you, then the argument would hold more weight. As it stands, obviously, my solution isn't appropriate for everyone, but it is most appropriate for me. my solution is rejection (not bouncing). my solution can have some adverse effects on other people as a result of someone else's malicious software, true. so does yours. just in a different way. I take the stand (as others on the list also have) that I am not, and can not be responsible for everyone I come into contact with either directly or indirectly. As much as I would like to help everyone, i'm neither qualified, nor is it entirely appropriate. At a certain point, people need to take responsibility for themselves. That includes being responsible for what they do and/or do not tolerate, how they deal with those things that they find they are unable to tolerate, and how to alter their environment so that they can protect themselves from those things they are unable to tolerate. The argument that i've seen here has been two-in-one. the first is that discarding is better than rejecting. for some, that is true and appropriate. the second, parallel argument is that the reason to discard is because people other than [insert admin/implementing authority/etc. here] are unable to accept or even understand responsibility for themselves and that we (the mail admin community) must accept responsibility for them and every other netizen instead of educating them as necessary for them to accept responsibility. This is the role of an enable
RE: [Mimedefang] ClamAV's Worm/Trojan/Joke/W97M classifications
On Fri, 1 Jul 2005 09:05:37 -0400, Chris Gauch wrote > Alan wrote: > So, [EMAIL PROTECTED] would be infected (where a virus, such as > W32.Bagle, would be auto-generating email from their PC and sending > out copies of itself), sending out the virus using a forged FROM > address from [EMAIL PROTECTED], and our mail server would reject > and generate a bounce to user-y, containing the virus attachment in > the NDN. The problem here is you were not rejecting.. you were bouncing.. there is a HUGE DIFFERENCE. With a 5xx reject you tell the MUA/MTA you are not accepting the message for delivery and why, you do NOT generate a bounce. (yesyes, I know if the IP happens to be a valid MTA it may or may not generate a bounce, that is a different situation altogether though and IMHO a rare one where you do nto control both MTAs and can fix it anyway). Bouncing virus infected email (or spam for that matter) makes absolutely NO sense. Jim -- EsisNet.com Webmail Client ___ 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] ClamAV's Worm/Trojan/Joke/W97M classifications
On Fri, 2005-07-01 at 08:24, Jim McCullars wrote: > > No, this is the other side of the same SMTP conversation. I'm asking > > you to consider what a rejection sets in motion. > >Because I am scanning at the MX for my domain, and because the vast > majority of these viruses come from a hijacked PC with its own SMTP engine > that don't do returns, I think that most of them end there. Once again, consider what happens in this scenario: a new virus is introduced that your scanner doesn't catch yet. A machine in your domain is sending messages with every permutation of addresses it can find in it's contact list and received emails as the To: and From: addresses through your outbound relay. A receiving relay has a better scanner or just pulled the update that catches this one. Would you prefer it to drop the message quietly or issue a reject, knowing that the bounce to the forged From: is very likely to infect another one of your user's machines? If there are 8,000 new viruses introduced in a year and it takes several days to identify them in the scanners, this is not at all unlikely. Our company submitted one to McAfee, Symantic, and Clam on a weekend and the update didn't include it until Tuesday for McAfee and Symantic, and Clam didn't add it until we resubmitted with one of the commercial scanner's identifiers. That one was generating so much network traffic that it literally took down the network - our redundant Cisco's both decided to take over because they couldn't see each other's HSRP heartbeats. After that experience I'm convinced that anything that identifies a virus should do everything possible to make sure it does not reach another windows machine. > > There really is no question about what you have to do with a negative > > DSN from the next MTA. Likewise they have no choice about what to > > do when you issue one. > >Again, you are assuming that these virus programs perform to standards. > I think this is an erroneous assumption. No, I am talking about programs that forward through the relay they find configured in outlook. Some do, some don't. I'd expect more and more to do that, or try both ways as more ISPs block port 25 to home connections except to their own relays. The reason viruses keep getting worse is that each new one can combine all of the old ways of spreading to have a better chance to spread before the scanner definitions start to block them. -- Les Mikesell [EMAIL PROTECTED] ___ 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] ClamAV's Worm/Trojan/Joke/W97M classifications
On Fri, 2005-07-01 at 09:45, James Ebright wrote: > (yesyes, I > know if the IP happens to be a valid MTA it may or may not generate a bounce, > that is a different situation altogether though and IMHO a rare one where you > do nto control both MTAs and can fix it anyway). For any definition of 'valid MTA', an SMTP rejection *will* generate a bounce. For any recent virus and much spam, the bounce will go to some innocent and unrelated address, which may in fact be the intended target. > Bouncing virus infected email (or spam for that matter) makes absolutely NO > sense. By definition, sending an SMTP rejection forces a bounce to be generated by an MTA. It is really irrelevant other than the amount of work involved whether your machine composes it or not. -- Les Mikesell [EMAIL PROTECTED] ___ 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] ClamAV's Worm/Trojan/Joke/W97M classifications
Les Mikesell wrote: For any definition of 'valid MTA', an SMTP rejection *will* generate a bounce. For any recent virus and much spam, the bounce will go to some innocent and unrelated address, which may in fact be the intended target. As an example, some Mytob(?) variants forge addresses like [EMAIL PROTECTED] or [EMAIL PROTECTED] (The virus in question masquerades as an account suspension notice.) For various reasons, we reject anything coming in from outside claiming to be from those addresses with "554 5.7.1 Forgery attempt detected: you do not have permission to send using this address." Naturally, several times a week we get NDRs sent *to* those addresses explaining that the message "we" tried to send could not be delivered. Clearly, for whatever reason some of these *are* being relayed through a real MTA. Half the time the target address doesn't even exist, and we would still be getting the "User unknown" NDRs if we weren't rejecting them in filter_sender. -- Kelson Vibber SpeedGate Communications ___ 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] ClamAV's Worm/Trojan/Joke/W97M classifications
On Fri, 1 Jul 2005, Les Mikesell wrote: > addresses through your outbound relay. A receiving relay has a > better scanner or just pulled the update that catches this one. Would > you prefer it to drop the message quietly or issue a reject, knowing We can play these hypothetical what-if games until the cows come home. The operating parameters that I run under are based on my experience with the here and now. What concerns me more is something like this: Suppose a researcher emails a proposal to a military agency (our campus lives off of its contracts and grants). If that better-than-my virus scanner on the other end mistakes my researcher's PDF file for a virus, then yes, I want it to let me know the email was not delivered. > that the bounce to the forged From: is very likely to infect another > one of your user's machines? If that's a concern, then enabling sendmail's nobodyreturn option is probably in order. > they couldn't see each other's HSRP heartbeats. After that experience > I'm convinced that anything that identifies a virus should do > everything possible to make sure it does not reach another windows > machine. Again, as another member of this list so sagely noted, a policy decision like that really depends on the expectation of the system administrator's user base and his relationship with them. Jim McCullars University of Alabama in Huntsville ___ 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] Re: ClamAV's Worm/Trojan/Joke/W97M classifications
On Thu, 30 Jun 2005, Matthew Schumacher <[EMAIL PROTECTED]> wrote: There is another case where rejecting is better that hasn't been bought up yet (or at least I didn't read it) password protected zip archives. On our mail system we call these viruses simply because they almost always are, but if we where silently dropping them then that would be a problem. Many viruses use their own SMTP engines, which just keep pumping the sludge, no matter how many 5xx errors you throw at them, and they do not display the mail server rejection messages to the local user. We deal with this issue by running a script against our mail server logs twice daily to identify systems in our net blocks which have submitted virus carrier messages to our SMTP servers. -- Paul Russell Senior Systems Administrator OIT Messaging Services Team University of Notre Dame ___ 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] ClamAV's Worm/Trojan/Joke/W97M classifications
On Fri, 2005-07-01 at 12:38, Jim McCullars wrote: > The operating parameters that I run under are based on my experience with > the here and now. Agreed - it took my own experience to convince me that knowingly participating in any fashion in virus delivery was an evil thing. A couple of years ago I would have argued on the other side (and probably did). I just don't want people to pretend that sending a 5xx rejection is any different than sending a bounce yourself when you are talking to any real MTA or claim that its not 'their fault' that a bounce is sent. >If that's a concern, then enabling sendmail's nobodyreturn option is > probably in order. That adds another copy if I remember correctly. -- Les Mikesell [EMAIL PROTECTED] ___ 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] False positives in filter_bad_filename
Some users are complaining MIMEDefang blocks some attachs in legitimate
mail. The attachs are mostly Excell or Word documents with names like
this:
Fondo Fijo inform. balance.xls
as you can see from the logs:
Jul 1 13:19:23 mail2 mimedefang.pl[21359]: MDLOG,j61GJNn3023427,bad_filename,Fondo Fijo
Agencia inform. balance.xls,application/vnd.ms-excel,<[EMAIL PROTECTED]>,<[EMAIL
PROTECTED]>,AGENCIA MENDOZA- FONDO FIJO AL 30/6/2005
Jul 1 15:27:19 mail2 mimedefang.pl[24289]: MDLOG,j61IRJn3026073,bad_filename,Fondo Fijo
inform. balance.xls,application/vnd.ms-excel,<[EMAIL PROTECTED]>,<[EMAIL
PROTECTED]>,Fw: cierre de balance al 30.06.05
Jul 1 15:36:29 mail2 mimedefang.pl[24289]: MDLOG,j61IaTn3026247,bad_filename,Fondo Fijo
inform. balance.xls,application/vnd.ms-excel,<[EMAIL PROTECTED]>,<[EMAIL
PROTECTED]>,Re: cierre de balance al 30.06.05
I thik the fact that the filename has a "." and lots of blank spaces in it
triggers the false positive but I couldn't find where.
iI wrote a "bare bones" version of filter_bad_filename to check it:
#!/usr/bin/perl -w
$bad_exts =
'(ade|adp|app|asd|asf|asx|avi|bas|bat|chm|cmd|com|cpl|crt|dll|exe|fxp|hlp|hta|hto|inf|ini|ins|isp|jse?|lib|lnk|mdb|mde|mov|mpe?g|mp3|msc|msi|msp|mst|ocx|pcd|pif|prg|reg|scr|sct|sh|shb|shs|sys|url|vb|vbe|vbs|vcs|vxd|wmd||wmv|wms|wmz|wsc|wsf|wsh|\{[^\}]+\})';
$re = '\.' . $bad_exts . '\.*$';
while (<>) {
print "Match!" if ($_ =~/$re/);
}
and I tried it with
echo "Fondo Fijo inform. balance.xls" | perl re_test.pl
but it didn't return a match.
Can anyone tell me why the attach was rejected? and what can I do to fix it
Thanks in advance
Fer
___
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] ClamAV's Worm/Trojan/Joke/W97M classifications
> The problem here is you were not rejecting.. you were bouncing.. there is > a > HUGE DIFFERENCE. With a 5xx reject you tell the MUA/MTA you are not > accepting > the message for delivery and why, you do NOT generate a bounce. (yesyes, I > know if the IP happens to be a valid MTA it may or may not generate a > bounce, > that is a different situation altogether though and IMHO a rare one where > you > do nto control both MTAs and can fix it anyway). > > Bouncing virus infected email (or spam for that matter) makes absolutely > NO sense. > In response I would just reiterate the point that Les Mikesell made -- a 5xx rejection always (or should always) result in a bounce, whether generated by your SMTP server or someone else's. In circumstances where the mail stays in your own environment and ONLY goes across relays where you are setting the policies, what you are stating could feasibly be accomplished. However, as soon as you deal with SMTP hosts OUTSIDE your realm, your rejection will ultimately end up generating a bounce back to the sender, whether forged or real. - Chris -- Chris Gauch Systems Administrator Digicon Communications, Inc. http://www.digiconcommunications.com [EMAIL PROTECTED] (716) 583-1254 ___ 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] ClamAV's Worm/Trojan/Joke/W97M classifications
Alan Premselaar wrote: > I'm not generating bounces... i'm merely 550 rejecting ... which is fine > in my situation because it's the SMTP outgoing gateway machine that is Well, you may not be generating the bounces, but someone else is. The next step in a standards-conforming MTA after a reject is to wrap the message in an NDN and return it to the sender. Maybe you're not doing it, but the remote SMTP server (if it is a LEGIT server) is certainly bouncing. I see your point though, in a virus using its own SMTP engine, the reject stops the message in its tracks since the virus SMTP engine is not capable of handling the rejection properly. > > we have instituted a no MS internet software policy, but it doesn't > necessarily mean that someone's not going to open OE or IE out of habit > or just cuz they think they know what they're doing. Consider yourself lucky...if I could get the bosses at my place to agree to a "no MS software", or better yet, "no Windoze", I'd be in paradise compared to where I am now. > if AV scanners were absolutely, without a doubt 100% reliable, that > would be a different story. if there were NO OTHER WAYS to contract > these viruses, it would be a different story. if there weren't other > legitimate causes for DSNs, NDN, or whathave you, then the argument > would hold more weight. You won't get an argument out of me that AV scanners are 100% reliable; even in my situation viruses have gotten through (although VERY rarely because of our sendmail config, greylisting, greet delays, connection rate throttles, SMTP user existence checking, and everything else we have going on to stop crap mail from getting through to business clients), but I will confidently say that if an AV scanner FLAGS a message as a virus, chances are about 100% that it IS, IN DEED, a virus -- no ifs, ands, or buts. - Chris -- Chris Gauch Systems Administrator Digicon Communications, Inc. http://www.digiconcommunications.com [EMAIL PROTECTED] ___ 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] ClamAV's Worm/Trojan/Joke/W97M classifications
Les Mikesell wrote: > If there are 8,000 new viruses introduced in a year and it takes > several days to identify them in the scanners, this is not at all > unlikely. Our company submitted one to McAfee, Symantic, and Clam > on a weekend and the update didn't include it until Tuesday for > McAfee and Symantic, and Clam didn't add it until we resubmitted > with one of the commercial scanner's identifiers. That one was > generating so much network traffic that it literally took down the > network - our redundant Cisco's both decided to take over because > they couldn't see each other's HSRP heartbeats. After that experience > I'm convinced that anything that identifies a virus should do > everything possible to make sure it does not reach another windows > machine. Les, that was very well-stated. This all relates somewhat to a point I made earlier about seeing things from the virus writer's perspective. A halfway-intelligent virus writer (and we're talking about someone with at least the IQ of a dog) knows how the SMTP system works, and if they want widespread distribution as cheaply as possible, they're going to know the SMTP/MTA systems to a good degree, and especially how to exploit them. The virus writer knows that his/her message is going to get caught rather quickly by relays running AV scanners, so it's really the rejection, and then the bounce, that they're depending on. I would encourage others to look at the FROM and TO address patterns that viruses use in their auto-generated emails. In almost EVERY case, the TO address appears to be some sort of dictionary-driven process (which leads me to believe the virus writer couldn't give a crap about who the message is being sent TO), but the FROM address, that is almost always real (and from someone's Outlook contacts/address book). Now, what can you say was the true intention of the virus writer? - Chris -- Chris Gauch Systems Administrator Digicon Communications, Inc. http://www.digiconcommunications.com [EMAIL PROTECTED] (716) 583-1254 ___ 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] ClamAV's Worm/Trojan/Joke/W97M classifications
On Fri, 1 Jul 2005, Chris Gauch wrote: > Well, you may not be generating the bounces, but someone else is. The next As many have stated (repeatedly) in this list, this is not necessarily the case. This is starting to take on the characteristics of a religious discussion. For what it's worth, I have refrained from stating what I think the ideal policy is, and tried to stick to just replying to what I think is misinformation that is being posted as fact. For those reading this list in the USA, Happy Fourth! Jim McCullars University of Alabama in Huntsville ___ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
