Re: [Clamav-users] sol8 compile problem
I believe you will find notes in the installation readmes regarding solaris in that you must include ABI=32 into the configure string ./configure ABI=32 --prefix= Bill Cocoon wrote: Hello List, I want to compile the new clamav version 0.85.1 on a solaris 8 system Whit the command ./configure -prefix=/var/amavis/clamd every thing works fine. Then I make the make an got this error at the end! Any ideas? ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] sober.p and german adverts?
Bart Silverstrim wrote: On May 17, 2005, at 4:03 PM, Bill Taroli wrote: Steffen Winther Soerensen wrote: This seems more like a discussion for another mailing list or a Usenet group on MTAs/SMTP IMHO I don't disagree... are there any good ones for SPF or similar debates? I do think -- much as you'd find in the Amavisd list -- that these issues do tend to intersect and overlap in various ways. While clamav is obviously about virii, it routinely gets deployed right along side spam and other tools. I'd argue that ClamAV is no longer even "just an AV". It was crossing the line to "malware detector" when it started filtering phishing attempts that have nothing to do with viruses, much as Spybot now detects several Bagle variants. Not saying it's good or bad...just stating the way it appears to be from this observer's viewpoint. Good point. That said, I do admit this discussion probably would have been better received in the SPF mail lists. Already been reading them some and figure that this discussion might well move there. :-) Bill ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] sober.p and german adverts?
Dennis Peterson wrote: [EMAIL PROTECTED] said: On Tue, 17 May 2005, Dennis Peterson wrote: I guess I'm saying that if I telnet to fw.domain.name on 25, I should see something like 220 fw.domain.name ESMTP mail relay. If it doesn't say that, then it is lying to anyone who connects to it. Forward and back dns should resolve to the name spit out by the smtp 220 string. This should be verifiable. If I have a server with 500 virt hosts you could get a helo from any one of them. If you telnet back to it on port 25 what do you think you might see? One of about 499 "liars", maybe? Well I am assuming that you would be doing a forward-reverse-forward to and comparing it to there. If a forward of mail.someclient.com is 1.2.3.4 and a reverse of 1.2.3.4 is fw.domain.name and a forward of fw.domain.name is 1.2.3.4 then it's not lying. In fact, that is quite common. I'm saying there should be a consistent forward-reverse mapping for the actual mail server and that that mapping should match the 220 string. If someclient.com has more than one priority MX server to handle mail then whatever server is handling it (fw2.domain.name?) should have proper forward-and-back mappings. I give up. I was really thinking the light was about to go on, too. Actually, I think you're agreeing and don't realize it. If I read the point properly, he is not suggesting that the name returned in PTR necessarily match that of the 220 reply... but he is suggesting that the forward lookup against the 220 reply result in an IP consistent with what you looked up in PTR originally. And, yes, this is pretty typical of hosted setups. If my IP results in domain.com but my mail server 220 says domain.org, that's OK... because both of them forward lookup to the same IP. Or did I misunderstand the posting? Bill ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] sober.p and german adverts?
Julian Mehnle wrote: Bill Taroli wrote: Eric Wheeler wrote: [...] For email transfer and MTA's alike, putting SPF in DNS to help "authenticate" the source is a step in the right direction. If SPF is a good idea, and it is dns based, then so should forward-and-back lookups. I totally agree that some solution is desirable to these issues. There are several efforts underway, including SPF -- which now appears (according to a recent visit to http://spf.pobox.com/) to be a formal part (or companion) to Sender ID. Uhm, no. There is SPF (AKA SPF Classic), and there is Sender-ID. S-ID is based on SPF, but SPF is independent from S-ID. I did say "(or companion)", no? :-) And the other part of Sender ID is Microsloth, yes? I shudder at the thought of Microsoft's involvement, other than the potential benefit of better security in their products -- to avoid impact to the rest of us. The SPF project is currently working to set up a new website. Significant parts of http://spf.pobox.com are outdated. Glad to hear it. It's where I usually send folks asking about SPF -- or when I send other admins email about why their mail is getting rejected and to get more information. But this is mostly off-topic here. For more information, join the spf-discuss mailing list: http://spf.pobox.com/mailinglist.html Thank you for the pointer. Finished subscribing a few minutes ago. Bill ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] sober.p and german adverts?
Matt Fretwell wrote: [EMAIL PROTECTED] wrote: IMO, a sending MTA should never have its smtp port closed unless it is an end-user. Once again, a sending server does not have to be a MX. Something within that domain should be listening on port 25, but not always the machine which is connecting to yours. Look at the hostname of my machine in the headers. You will see it has rDNS and fDNS, but is not a MX for the domain. I think that was a typo, since the criteria he gave say "the domain has an MX that..." and not "the MTA is an MX that..." Basically, just edit "sending MTA" to "MX for the sender's domain" and I think we're good. :-) Bill ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] sober.p and german adverts?
Bart Silverstrim wrote: On May 17, 2005, at 3:21 PM, [EMAIL PROTECTED] wrote: On Tue, 17 May 2005, Damian Menscher wrote: Would the person who implements this do me a favor and make the virus pretend to be a viagra spam? If we format the hard drives of people that buy from spammers, and the media picks up on it, then everyone will be informed of how dangerous spam is. Nobody will click it anymore, and spammer profits will plummet. This has a very real chance of eliminating the spam problem. Kill two birds with one stone... I like it. Nice. That couldn't be cleaner. There are plenty of ways of harmlessly disabling a system (no lost data, just no boot) and that would certainly be an awakening call for everyone across the board. People would get to reinstall their os and loose at least 2hrs of time. I really miss the days of destructive viruses. We just don't really see 'em like we used to. Remember Michaelangelo? What was his birthday again? /me stops reminiscing of the good ol' days. Actually I don't know if users would be effected by an hour or two charge of reinstalling the OS. Lose their favorite bookmarks or the report they were working on, they might remember that. But just hitting "next" a couple times...then again, re-entering a 50 digit key and reactivating XP is a pain in the butt. :-) No, I wouldn't delete files... just replace their content with repeated strings of "I won't click on links in Viagra emails" or "I won't randomly click on links to unknown web sites" ... :-) ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] sober.p and german adverts?
Steffen Winther Soerensen wrote: This seems more like a discussion for another mailing list or a Usenet group on MTAs/SMTP IMHO I don't disagree... are there any good ones for SPF or similar debates? I do think -- much as you'd find in the Amavisd list -- that these issues do tend to intersect and overlap in various ways. While clamav is obviously about virii, it routinely gets deployed right along side spam and other tools. Bill ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] sober.p and german adverts?
Matt Fretwell wrote: [EMAIL PROTECTED] wrote: If we can standardize the set of rules and protocols required for an MTA to accept an email, then spam will reduce. Either that or we need to build a better mousetrap. This is jut my $0.02. What time is the next rocketship to this planet you have found? :) Now, now. I agree it's a lofty goal... but I think it's a worthwhile one. It's how we respond to the challenge that will determine our ultimate success. I move that we kick Microsoft out of the game with their proprietary solutions, for a start. Keep the focus on effective, easily implementable, STANDARD, and **OPEN** solutions and I think we'll be quite successful. Then the remaining challenge is getting the word out and getting people to adopt these solutions. I can't gauge how far SPF has spread yet, but in my own spot checking, I'm finding an increasing number of senders that my MTA sees are being positively or negatively acknowledged by SPF, rather than just "none", "neutral", or "unknown" cases. Still in the minority, but growing... to the point that I finally threw the lever on kicking responses that come back "error" or "failed". Bill ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] sober.p and german adverts?
[EMAIL PROTECTED] wrote: On Mon, 16 May 2005, Bill Taroli wrote: Matt Fretwell wrote: plenty of legitimate MTA setups running on dynamic IP's. [...] What really does amaze me though, is that these are generally the admins who will turn around and say, 'Don't block (variable), you will lose too much legitimate mail'. Where is the logic in that? They will allow a crappily configured multinational corporation or ISP to connect, yet not give dynamics the slightest chance to prove their reliability. I don't think it's a matter of reliability... it's more an issue of accountability and traceability. How can one trace back to a dynamically IP'ed MTA when it's dynamic? [...] I don't disagree that there may well be many people running wholesome MTAs on dynamic IP's that suffer for the rest. But it's that rest we're all concerned with. I honestly wonder whether an authorization framework such as SPF would be the salvation of such setups... permitting them to prove themselves worthy without the need for static IP addresses. But until that time comes, any host who appears to lie about it's identity by giving a host name that doesn't match it's visible IP address is getting the door slammed in it's face by my MTA. [...] For email transfer and MTA's alike, putting SPF in DNS to help "authenticate" the source is a step in the right direction. If SPF is a good idea, and it is dns based, then so should forward-and-back lookups. I totally agree that some solution is desirable to these issues. There are several efforts underway, including SPF -- which now appears (according to a recent visit to http://spf.pobox.com/) to be a formal part (or companion) to Sender ID. Sender ID scares me a little, since it's proprietary. I firmly believe that we need (truly, not Microsoft's flavor of) open standards in this area. SPF doesn't come without issues, mostly in the area of how to deal with mail lists and such, but it's totally better than nothing at all. In just the same way though, I would be curious about how far one would take the PTR lookup. Just that there is one? That it matches the actual name of the host? I mention the latter because it could cause problems in hosting situations, where a single IP address might legitimately be used by dozens (or even hundreds) of domains. And you have have just one PTR record for it. SPF handles this case nicely, because you can set up clear relationships between the domains from that host and it works well. What discourages me, though, is that many mail admins can't seem to get their *forward* lookups right, let alone the reverse. ;-) I wavered on whether I'd strictly enforce this after I found how many were broken, and I've ultimately taken the stance that I will absolutely reject their mail, and then inform their admins (and the affected sender) that they have a problem and, yes, it is preventing their mail from being received. I don't even mind doing this for spammers in some cases... sort of making a point. ;-) If additional mail standardization can take place (again) then spam can be reduced to a certain degree. I much like Brian Read's idea of blocking mail xfer from sites which are not authenticated (SASL) or who cannot give a proper reverse lookup. I've already noted concerns about reverse lookup -- I'd prefer SPF in those situations. As for SASL... well, now that would be interesting wouldn't it? I can see definite advantages.. much like one would have experienced in the UUCP days. You know and trust who your neighbors are, and as long they in turn only hand off to trusted folks then the likelihood of keeping the spammers out would improve. It doesn't really do much for the trojan or worm case, so I guess some kind of ROI would need to be established before putting people through the paces of building networks of trusted MTA's. The truth is that no solution will be perfect... we just need to find something that's effective and yet doesn't add unduly to the administration requirements or cost. I like solutions like SPF for this because with a few DNS entries and compliant MTA's, a world of good could be done. Efforts like Sender ID (and Domain ID... if I remember the name correctly) add another layer, but I fear Microsoft's entry sacrifices too much in the way of being proprietary while it insists that it's an open standard -- they love these sorts of contradictions. Every ISP we have worked with have been happy to create or change a PTR entry in their dns, even if it took a lot of work to get the ISP to do so (I even offered to do it for one isp and they finally did it themself). Yes, people are usually just unaware that their configuration is problematic as others roll out solutions to prevent spam, etc. I'
Re: [Clamav-users] sober.p and german adverts?
Matt Fretwell wrote: Bart Silverstrim wrote: Maybe even do a reverse check to see if there's a mail server on the sending system...how many systems would break doing a check like that? The sending server isn't guaranteed to be a MX, so any DNS MX or reverse connection tests would fail. But that doesn't mean you can't connect to an MX for the sender's domain to confirm they exist -- that you could send mail *to* them. This is a fairly regular check some mail systems perform. I was amused by one recent system that did this against my MX but did it from a host with a name that didn't match it's IP address, so mine rejected it... haha Bill ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] sober.p and german adverts?
Matt Fretwell wrote: Brian Read wrote: Block all mails from dynamic IP. They are 99,99% spam. No they aren't that "rule" causes quite a few of my customers a headache, as the (linux) mailserver I often install sends the email direct, irrespective of whether there Ip is "dynamic" or "static". Some ISPs charge an arm and a leg for static IPs. [...] This bumph about people shouldn't be allowed to run a direct MTA to MTA setup unless they have static IP's is nonsense. One might even say that it is MTA (elitism|snobbery). There are plenty of legitimate MTA setups running on dynamic IP's. [...] What really does amaze me though, is that these are generally the admins who will turn around and say, 'Don't block (variable), you will lose too much legitimate mail'. Where is the logic in that? They will allow a crappily configured multinational corporation or ISP to connect, yet not give dynamics the slightest chance to prove their reliability. I don't think it's a matter of reliability... it's more an issue of accountability and traceability. How can one trace back to a dynamically IP'ed MTA when it's dynamic? DynDNS doesn't prove itself in the majority of cases, or isn't even used. Some of these are even worse because the mail is coming from a NAT'ed host from behind a dyn IP firewall, which won't even allow return messages -- and I suspect this is extremely common. Kind of like an inverse roach motel for email. I don't disagree that there may well be many people running wholesome MTAs on dynamic IP's that suffer for the rest. But it's that rest we're all concerned with. I honestly wonder whether an authorization framework such as SPF would be the salvation of such setups... permitting them to prove themselves worthy without the need for static IP addresses. But until that time comes, any host who appears to lie about it's identity by giving a host name that doesn't match it's visible IP address is getting the door slammed in it's face by my MTA. YMMV. Bill Matt ___ http://lurker.clamav.net/list/clamav-users.html ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] sober.p and german adverts?
Brian Read wrote: Block all mails from dynamic IP. They are 99,99% spam. No they aren't that "rule" causes quite a few of my customers a headache, as the (linux) mailserver I often install sends the email direct, irrespective of whether there Ip is "dynamic" or "static". Some ISPs charge an arm and a leg for static IPs. I wind up blocking mail from people like that for an entirely different reason. Basic DNS checking against the HELO string to be sure it resolves to the IP address the connection's actually coming from. I couldn't imagine how much spam I don't even have to waste cycles filtering as a result. :-) Mind you, I wind up having to send "your mailserver isn't configured right" messages to some sites. But the reduction in the noise is well worth it. This attack, for example, would all but be completely blocked without a single invocation of SpamAssassin. :-) Unless of course they luck out and infect a PC that has a proper mail config. :-\ Bill ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Upgrade to 0.85 or wait for 0.86
Matt Fretwell wrote: Bill Taroli wrote: I completely agree with your point. But taken from a different perspective, this may be one reason to justify that such a product not be used in production IT environments. The point should *not* be missed that something so crucial to one's infrastructure -- that you would of course want to keep up to date -- should *require* updating on a weekly basis to solve *software* issues. Two points this brings forward. Firstly, and foremost, it does have to be accepted that Clam is still in pre version one state. Stability in any software can only be achieved after an extended period of updating and testing to make sure most avenues are covered. Things stabilise and level off eventually, but that cannot happen straight away from scratch. Which is exactly why it would be important for some people to choose to wait -- and not be forced or coerced by such dire warnings as (YOU ARE DOWNREV) in the log -- to implement when a new release comes out. Secondly, if something is that crucial to your infrastucture, (and if I've said it once, I've said it a thousand times), you should never have a single point of failure within a system. If you are not running a backup, then whatever comes is only to be expected. This applies to anything, not just AV scanning. Well, backup is one thing. Risk mitigation is another, and is why people needn't feel inferior for being one or two minor releases back (0.83??? for shame! ... and I was already getting those YOU'RE DOWNREV messages in my log as soon as 0.84 launched) when they read woes of issues found by more brave souls on the new releases. It goes hand-in-hand. But one thing is true... if we want good open-source products like this to go mainstream, then eventually they need to understand that people will expect more predictable performance (in terms of upgrades and allowing for a controlled release rather than jumping on every new dev build). And clamav and open-source aren't alone in this... to some extend all software products exhibit this problem, and why people (esp in IT) become so cautious about upgrading without evidence that others have done it without issue. :-) Bill ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Upgrade to 0.85 or wait for 0.86
Matt Fretwell wrote: Mark wrote: I understood your point perfectly. Why upgrade, using precious time, when another upgrade may be required very shortly, requiring said time to again be used. I am just pointing out a pitfall. There is always a good excuse not to do something. It is, however, exactly that. An excuse. Your pitfall could easily be turned around to say: "I understand developers rather have clients test out the product in the field, waiting for feedback on bugs and errors, rather than using precious time to do more thorough pre-release testing themselves, but this is just an excuse for not doing their own homework." It sure were nice if we could assume the absence of laziness on either side of the fence. Would you accept a hospital nurse telling you that they weren't going to set your broken arm in plaster 'because it will be healed in a week or two anyway, so you might as well just wait'? I think not. LOL. Well, depending on the kind of break they might very well say something like that! ;-) And yes, I will echo what Tomasz said in this regard. These gentleman|lady admins are paid to keep these systems in prime working condition, inclusive of updates for new threats or security exploits. Period. That is why they are called (I.T|Network) Administrators. I completely agree with your point. But taken from a different perspective, this may be one reason to justify that such a product not be used in production IT environments. The point should *not* be missed that something so crucial to one's infrastructure -- that you would of course want to keep up to date -- should *require* updating on a weekly basis to solve *software* issues. Obviously, keeping signatures up to date is extremely important. But if software is so buggy that regular code upgrades are required, one really needs to start wondering why that's the case... is it for functionality enhancements, or due to quality? ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] amavisd-new not using clamd
One thing I remember finding when I first installed p7 was that the clamv entry was only included in the @av_scanners_backup list. In order for it to be considered a primary, it has to be listed in the @av_scanners list, and I've had it running like that for a long time without trouble. But just because you might only have it in the backups list doesn't mean it won't be called. Are you saying that amavisd reports a failure at runtime indicating that no scanners could be found? Bill Tom Munro Glass wrote: I have installed ClamAv and amavisd-new to work with Postfix. They are mostly working except that when I start amavisd I get the following message in maillog: Found secondary av scanner Clam Antivirus - clamscan at /usr/local/bin/clamscan When a message is sent to amavisd for scanning I get the following message: WARN: all primary virus scanners failed, considering backups --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Clamav-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/clamav-users
Re: [Clamav-users] Amavisd-new and Clamav TCP
I've had amavisd-new and clamav talking over TCP for several weeks now
without any issues at all.
Hanford, Seth wrote:
I'm using ClamAV 0.67-1, currently using Unix sockets.
I'm not too familiar with UNIX sockets, but I'm comfortable with TCP sockets
and communication. Is clamd any more/less reliable when running over TCP?
I started clamd briefly using TCP and was able to connect and PING it, but I
can't get it to interface appropriately with amavisd-new. The following is
an excerpt from my amavisd.conf:
### http://clamav.elektrapro.com/
### Old socket name '/var/amavis/clamd'
['Clam Antivirus-clamd',
\&ask_daemon, ["CONTSCAN {}\n", '/var/run/clamd/clamd.sock'],
# \&ask_daemon, ["CONTSCAN {}\n", '127.0.0.1:3310'],
qr/\bOK$/, qr/\bFOUND$/,
qr/^.*?: (?!Infected Archive)(.*) FOUND$/ ],
The commented CONTSCAN line didn't work, but a similar one is found under
OAV and other TCP based scanners. Is this a correct syntax here? I can't
find an example on either Amavisd-new's site or ClamAV's for using
amavisd.conf with TCP connections.
Maillog entry when using UNIX sockets:
Mar 3 11:01:09 gabriel amavis[24627]: (24627-07) Clam Antivirus-clamd:
Sending
CONTSCAN /var/amavisd/tmp/amavis-20040303T103239-24627/parts\\n to UNIX
socket /
var/run/clamd/clamd.sock
Maillog entry when using TCP sockets:
Mar 3 10:27:48 gabriel amavis[8201]: (08201-01) Clam Antivirus-clamd:
Connectin
g to socket /var/amavisd 127.0.0.1:3310
Mar 3 10:27:48 gabriel amavis[8201]: (08201-01) Clam Antivirus-clamd: Can't
con
nect to INET socket 127.0.0.1:3310: Connection refused, retrying (1)
Thanks,
Seth
---
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
___
Clamav-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/clamav-users
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
Clamav-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/clamav-users
Re: [Clamav-users] password-protected Worm.Bagle.F
Perhaps a silly question... if the .ZIP attachment is passworded, how are the target users supposed to be opening them and getting infected? Has the password been included in the email in which the .ZIP was attached? Fajar A. Nugraha wrote: Fajar A. Nugraha wrote: So far (I only have two different samples now) the password is the same : 31517. Update : I just got another sample with different password (submission number 1534). Should I start blocking .zip files too? Regards, Fajar A. Nugraha --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click ___ Clamav-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/clamav-users
