Re: [Clamav-users] simplest replacement for ancient amavis-perl
Steve Wray schrieb: Tilman Schmidt wrote: [...] So dropping mail into the bitbucket is not an alternative. I have to either reject it or deliver it. Wow. So... the default, unpatched build of qmail is quite popular in Germany? I won't enter that minefield. :-) But unpatched qmail is certainly not the only MTA that can be run that way. That was Dans policy when he designed qmail; all mail must be delivered or bounced. That was the original policy of every serious MTA. There are other policy decisions in qmail which are more controversial. -- Tilman Schmidt Phoenix Software GmbH Bonn, Germany signature.asc Description: OpenPGP digital signature ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
Tilman Schmidt wrote: Am 11.08.2008 12:05 schrieb Ian Eiloart: In fact, if you accept the email, then silently discard it, then you effectively endorsing the validity of the email. You'll be improving the reputation of the original sender in the eyes of the ISP. Worse, it can even be a punishable offense. At least here in Germany, doing so for a third party's mail (which according to most lawyers also covers a company doing it for mail addressed to its own employees) constitutes Nachrichtenunterdrückung (message suppression), a felony punishable with up to 5 years in prison. (Talk about lawmakers' support in the fight against spam ...) So dropping mail into the bitbucket is not an alternative. I have to either reject it or deliver it. Wow. So... the default, unpatched build of qmail is quite popular in Germany? That was Dans policy when he designed qmail; all mail must be delivered or bounced. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
On Mon, 11 Aug 2008 11:33:00 -0400 (EDT), Charles Gregory wrote: it concerns me as to whether these remarks about 'big name' non-compliant MTA's still apply specifically to greylisting. I mean, I can't really imagine a 'big' (fortune 500?) company having an MTA that does not attempt to resend mail if it gets a 400 response from another MTA. I realize they break all sorts of other stuff. Non-compliant 'helo's and all that, but at least please tell me there isn't a 'big' company out there that is failing to handle 4xx codes properly (holding breath) One example is Arcor, a biggish German access provider. Their outgoing mailservers do resend mail on a 4xx error - but only after a delay of eight hours. That sort of delay is quite enough to upset many users. But Arcor's tech support doesn't see a problem with that. They even maintain it's RFC compliant. -- Tilman Schmidt Phoenix Software GmbH Bonn, Germany signature.asc Description: OpenPGP digital signature ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
On 11.08.08 09:30, Dennis Peterson wrote: There are some big names that play badly with greylisting. They play badly with greet-pause, too. A problem I've seen with greylisting is the round-robin MTA pool. Each is told in turn to come back later and if the pool is large it can take a long time to cycle through all of them. You have to be careful how you screen the addresses. DCC servers (rhyolite.net) have greylisting functionality built-in, and they are accessible through network. Such solution (or other that shares grelylisting DB) should prevent from some problems. Of course, servers with big queues that process mail with longer periods may cause such delays. This is a thing anybody who implements greylisting should know. I plan to implement greylisting on secondary MXes first - bigger delay there should not be a problem (and could even help in catching spam, this and other ways) -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Your mouse has moved. Windows NT will now restart for changes to take to take effect. [OK] ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
Am 11.08.2008 12:05 schrieb Ian Eiloart: In fact, if you accept the email, then silently discard it, then you effectively endorsing the validity of the email. You'll be improving the reputation of the original sender in the eyes of the ISP. Worse, it can even be a punishable offense. At least here in Germany, doing so for a third party's mail (which according to most lawyers also covers a company doing it for mail addressed to its own employees) constitutes Nachrichtenunterdrückung (message suppression), a felony punishable with up to 5 years in prison. (Talk about lawmakers' support in the fight against spam ...) So dropping mail into the bitbucket is not an alternative. I have to either reject it or deliver it. -- Tilman Schmidt Phoenix Software GmbH Bonn, Germany signature.asc Description: OpenPGP digital signature ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
--On 8 August 2008 13:06:00 -0400 rick pim [EMAIL PROTECTED] wrote: Gerard writes: Employing 'greylisting' would vastly improve the chances of eliminating the acceptance of SPAM at the MTA level. it certainly does. unfortunately, in practice, one of the prime advantages of greylisting -- the fact that it will never block 'real' mail -- turns out, um, not to be true. there are so many standards-noncompliant MTAs out there that greylisting does block real mail. (this is one of the things that makes me crazy.) If it's not standards compliant, it's not an MTA. RFC2821 defines the behaviour of an MTA, and anything that breaks the standard can't expect to deliver email. That's our policy here. (we still use it, of course.) rp rick pim [EMAIL PROTECTED] information technology services (613) 533-2242 queen's university, kingston --- You call this a *trial*?! This is nothing but a *kangaroo* *court* without the hoppy, furry guy! -- The Flash (TV) ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml -- Ian Eiloart IT Services, University of Sussex x3148 ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
--On 8 August 2008 14:16:49 -0400 David F. Skoll [EMAIL PROTECTED] wrote: Tilman Schmidt wrote: telnet isps-smtp-server 25 In my experience that's very unusual behaviour for a virus. The vast majority try to connect directly to the recipient's MX. I see both. Regardless, your responsibility as an MTA operator is to not emit backscatter. You can't be held responsible for backscatter emitted by an ISPs MTA when it hasn't detected a virus. The ISP should be requiring the sender to use authenticated, encrypted SMTP, and the ISP should be able to detect forged sender addresses (they ought not to accept sender email outside of domains that they own), and should treat them with great suspicion when they do. In fact, if you accept the email, then silently discard it, then you effectively endorsing the validity of the email. You'll be improving the reputation of the original sender in the eyes of the ISP. -- Ian Eiloart IT Services, University of Sussex x3148 ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
Hi there, On Mon, 11 Aug 2008 Ian Eiloart wrote: RFC2821 defines the behaviour of an MTA, and anything that breaks the standard can't expect to deliver email. That's our policy here. Hehe, I bet you'd change that policy pretty sharpish if the people sending the emails wanted to give you money! I would like to take your unbending approach, but unfortunately while people like macCom and Microdozey completely mess up their servers (not always the same way, and not consistently across all the servers) and many of our customer use them because they don't know any better, then we have to compromise. I'd suggest you can tolerate a little compromise as long as you're getting something accomplished. Sure it's a pain, but not as much of a pain as the very nearly 46,000 /24 networks that we're currently firewalling for (trying to) send spam, not to mention the many hundreds of far bigger networks which we drop for that and more serious offences, like being Romanian. Our firewall rules alone stop at least 95% of the crap, leaving things like milters and Perl with much less work to do, and much less sludge in the logs, so administrators have more time for the personal touch - compromises, for example - and making sure that the virus databases are effective. I think what I'm trying to say is that you need some human involvement in all this, or the risk of throwing out the baby with the bathwater is substantially increased. -- 73, Ged. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
Ian Eiloart writes: --On 8 August 2008 13:06:00 -0400 rick pim [EMAIL PROTECTED] wrote: in practice, one of the prime advantages of greylisting -- the fact that it will never block 'real' mail -- turns out, um, not to be true. there are so many standards-noncompliant MTAs out there that greylisting does block real mail. (this is one of the things that makes me crazy.) If it's not standards compliant, it's not an MTA. RFC2821 defines the behaviour of an MTA, and anything that breaks the standard can't expect to deliver email. That's our policy here. you're preaching to the choir. unfortunately, some of the offenders are high profile, fortune-500 companies. if l'il 'ol me gets told professor smith can't get mail from BloatedMegaCorp because you're blocking it, it doesn't MATTER if they're standards-noncompliant, it doesn't MATTER if they're not real MTAs -- i have to find a way for professor smith to get his email. (aside: there are many, many such examples.) rp rick pim [EMAIL PROTECTED] information technology services (613) 533-2242 queen's university, kingston --- There's too many people here! Maybe we should kill some! -- Flaming Carrot ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
On Mon, 11 Aug 2008, rick pim wrote: prime advantages of greylisting -- the fact that it will never block 'real' mail -- turns out, um, not to be true. there are so many standards-noncompliant MTAs out there .. some of the offenders are high profile, fortune-500 companies. Could I just clarify this discussion? It started out with a specific comment about greylisting, which I am preparing to implement. So naturally it concerns me as to whether these remarks about 'big name' non-compliant MTA's still apply specifically to greylisting. I mean, I can't really imagine a 'big' (fortune 500?) company having an MTA that does not attempt to resend mail if it gets a 400 response from another MTA. I realize they break all sorts of other stuff. Non-compliant 'helo's and all that, but at least please tell me there isn't a 'big' company out there that is failing to handle 4xx codes properly (holding breath) - Charles ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
Charles Gregory writes: but at least please tell me there isn't a 'big' company out there that is failing to handle 4xx codes properly (holding breath) does IBM count? their canadian arm was a problem for a while and i had to whitelist their outgoing MTA. this has since been fixed, but stuff like this pops up from time to time, usually for 'small' companies but occasionally for large. currently, the only thing in my graylisting whitelist file is (shudder) facebook. (don't get me started about them...) it's not (IMHO) enough of an issue to avoid using graylisting. just be aware that it IS an issue from time to time, and the occasional Big Player might well be involved. rp rick pim [EMAIL PROTECTED] information technology services (613) 533-2242 queen's university, kingston --- Better watch out, Carrot, or you're going to wind up as a Saturday morning cartoon character, just like Mr. T! Alright! That did it! -- Flaming Carrot ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
Charles Gregory wrote: Could I just clarify this discussion? It started out with a specific comment about greylisting, which I am preparing to implement. So naturally it concerns me as to whether these remarks about 'big name' non-compliant MTA's still apply specifically to greylisting. I mean, I can't really imagine a 'big' (fortune 500?) company having an MTA that does not attempt to resend mail if it gets a 400 response from another MTA. It depends. We changed our greylisting code to greylist after DATA rather than after each RCPT after observing the following behaviour from a big-name MTA: C:HELO S:220 smtp.example.net Go ahead C:MAIL FROM:[EMAIL PROTECTED] S:220 Sender OK C:RCPT TO:[EMAIL PROTECTED] S:451 Greylisted... try again later C:RCPT TO:[EMAIL PROTECTED] S:451 Greylisted... try again later C:DATA S:500 Need recipient first Oops! The MTA authors obviously hadn't checked their state machine carefully. Regards, David. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
Charles Gregory wrote: On Mon, 11 Aug 2008, rick pim wrote: prime advantages of greylisting -- the fact that it will never block 'real' mail -- turns out, um, not to be true. there are so many standards-noncompliant MTAs out there .. some of the offenders are high profile, fortune-500 companies. Could I just clarify this discussion? It started out with a specific comment about greylisting, which I am preparing to implement. So naturally it concerns me as to whether these remarks about 'big name' non-compliant MTA's still apply specifically to greylisting. I mean, I can't really imagine a 'big' (fortune 500?) company having an MTA that does not attempt to resend mail if it gets a 400 response from another MTA. I realize they break all sorts of other stuff. Non-compliant 'helo's and all that, but at least please tell me there isn't a 'big' company out there that is failing to handle 4xx codes properly (holding breath) There are some big names that play badly with greylisting. They play badly with greet-pause, too. A problem I've seen with greylisting is the round-robin MTA pool. Each is told in turn to come back later and if the pool is large it can take a long time to cycle through all of them. You have to be careful how you screen the addresses. dp ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
-Original Message- There are some big names that play badly with greylisting. They play badly with greet-pause, too. A problem I've seen with greylisting is the round-robin MTA pool. Each is told in turn to come back later and if the pool is large it can take a long time to cycle through all of them. You have to be careful how you screen the addresses. dp The greylisting scheme I have implemented works at the DATA phase. It uses the sender IP address (top 24 bits only), the sender e-mail address and header date field to form the key for the message. Once a message has passed the greylist test the original sender IP address (full 32 bits) is placed in a whitelist. So, a particular server only needs to demonstrate once that it re-tries and will then be let through in future. By using the top 24 bits of the IP address in the key I hope to cope with a message being re-tried by a different MTA. I have not encountered such a problem yet. I have had a couple of instances where there was a problem because people had written their own code on web servers. They did not re-send the same message, but re-generated it when re-trying and so gave it a new date header. In both cases they modified their code when I explained the problem. Phil. Phil Chambers Postmaster University of Exeter ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
On Mon, 11 Aug 2008, David F. Skoll wrote: S:220 smtp.example.net Go ahead C:MAIL FROM:[EMAIL PROTECTED] S:220 Sender OK C:RCPT TO:[EMAIL PROTECTED] S:451 Greylisted... try again later C:RCPT TO:[EMAIL PROTECTED] S:451 Greylisted... try again later C:DATA S:500 Need recipient first These same sites have problems when a primary mail server is having trouble, they never try the secondary, then complain we are 'rejecting' their mail. Not even that gets it fixed. Oh well. == Chris Candreva -- [EMAIL PROTECTED] -- (914) 948-3162 WestNet Internet Services of Westchester http://www.westnet.com/ ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
Charles Gregory wrote: Non-compliant 'helo's and all that, but at least please tell me there isn't a 'big' company out there that is failing to handle 4xx codes properly (holding breath) Try: hotmail.com bigpond.com optusnet.com.au yahoo.com [for groups particularly...] Greylisting is working very well for me, but I must have a reasonable whitelist that excludes the above 'big' names so that they work! Kind Regards AndrewM Andrew McGlashan Broadband Solutions now including VoIP Current Land Line No: 03 9912 0504 Mobile: 04 2574 1827 Fax: 03 9012 2178 National No: 1300 85 3804 Affinity Vision Australia Pty Ltd http://www.affinityvision.com.au http://adsl2choice.net.au In Case of Emergency -- http://www.affinityvision.com.au/ice.html ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
Hi all, On Sat, 9 Aug 2008 [EMAIL PROTECTED] wrote: all kinds of different takes on it :) FWIW, as you know by now I'm in the 'let them know there's a problem' camp. But, well, it was just a suggestion. It was interesting so see the response to my post, obviously there are some strong feelings. Yes we do very occasionally see hundreds of thousands of backscatter mail messages. No, it isn't an embarrassment, our automatic defences will quickly shut them down, and I don't feel I want to kill the messenger. To take this one stage further, I think simply using ClamAV to block all your spam might be too simplistic; it's possible to deal with the vast majority of junk relatively painlessly, and leave ClamAV and such resource-intensive processes to deal with the rest. We generally use seven different milters. They log their actions, and a couple of Perl scripts scan the logs for various patterns of activity. The scripts will write firewall rules when the activity triggers some criterion, and hey presto no more crap from that particular source. It might be argued (I expect it probably will...:) that this is yet another source of backscatter, but I really don't see how I can be expected to run a mailserver just so that people can send spam to it without causing any inconvenience for anyone else. It's garbage. I don't want it. Period. On the point about accepting and then rejecting, no, you misunderstand the SMTP conversation. It is perfectly possible to read an entire mail message and yet still reject it. That's in part what ClamAV is about - you can't know if there's a nasty payload unless you've read it. Then you have to decide what to do about it. Let's all try to remember that the villains in the piece are the criminals. They make all this wasted effort necessary. If there are problems, by and large it's the criminals that cause them. Perhaps you might include incompetent, careless, witless and, if you wish, uncompromising computer operators, but they're not the root cause. -- 73, Ged. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
G.W. Haywood wrote: On the point about accepting and then rejecting, no, you misunderstand the SMTP conversation. It is perfectly possible to read an entire mail message and yet still reject it. Presuming you mean the message is read up to the final cr.cr, this is true. It is the last decision point for accepting or rejecting the message. That is the point at which delivery responsibility changes from the sending MTA to the recipient MTA. It is also possible the sending system will send the final cr.cr and drop the connection before receiving the status - spammers have no use for the status. But it's worth knowing what happens with the message and your MTA when the connection is dropped at that instant. Beyond that, some MTAs will accept responsibility for message handling and then later discover it is not deliverable. They then send an NDR to the From: address which can be any random string that looks like an email address. Often it is a real address with an active mail box and so that is where the NDR goes. This is allowed by the RFCs but is incredibly stupid to allow. The problem is often a matter of the secondary not having a current (or any) list if valid users. This even happens when the primary is not privy to the valid user base but simply throws incoming mail to an Exchange server inside the firewall. It can also happen when multiple MX servers for a domain have dissimilar filtering, for example. The secondary with weaker filtering accepts the message and delivers it to the primary which rejects it. The secondary still has the delivery responsibility and is compelled to send an NDR to the original sender so somebody's granny gets spammed. Back to the original discussion - nothing I've read has convinced me that using 5xx codes is anything but a good idea, and it allows me to focus on problems in my own part of the net and more importantly to ignore problems others are having because they are too altruistic, or too misconfigured. dp ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
Hi there, On Fri, 8 Aug 2008 jef moskot wrote: Re: simplest replacement for ancient amavis-perl Currently, we accept all infected mail, and quietly quarantine it. May I suggest that you quarantine it, BUT STILL REJECT IT after it has been read (and recorded) in its entirety? You're making a rod for your own back if you accept bad mail. The sender will sell the recipients' addresses to all his spammer friends and you'll just get more of it. We don't refuse it at SMTP connect, although I might be able to be convinced that that's a better idea. You can reject it all the way up to the last dot (er, period). ... I was looking at clamav-milter, which looks simple and also comes with the benefit of a community I'm comfortable with. Many of us here have been using it for years with no problems. I'll second that about the community. I can't find any decent documentation on it, however, (if I'm missing something obvious, please point me at it!) There's quite a lot on the Web but when you download and extract the source tarball you should have all you need. ... and it seems to jam mail at SMTP connection time rather than accepting and scanning later. SMTP conversation, not connection, but that's the best place really. There are other ways to use it of course. You can just insert a mail header as a flag and pass it through, leaving e.g YetanOtherMilter or something like SpamAssassin to decide. Personally, I like mail that will be rejected to be rejected at the earliest possible opportunity so that it doesn't waste everybody's money. I've found references to using it to quarantine messages, which would be perfect, but I haven't seen the docs to explain how to do that. After you install it, you can do man clamav-milter [snip] -A, --advisory When in advisory mode, clamav-milter flags emails with viruses but still forwards them. The default option is to stop viruses. This mode is incompatible with --quarantine and --quarantine-dir. [snip] and man clamd.conf etc. etc. (SEE ALSO clamd(8), clamdscan(1), clamav-milter(8), clamscan(1), freshclam(1), sigtool(1)) If you want to look at those before installing them they're in the docs/man directory after extracting the tarball, just do man docs/man/clamav-milter.8 or whatever. Also I've found some explanations of how to compile clam to get the milter, but those were in connection with FreeBSD ports, and I don't like to have to wait until an update has been bundled before I can deploy it. You can just grab the source tarball and compile and install it like you would for any almost other Open Source tool. The instructions are in the tarball itself. Granted there's a slight chicken-and-egg thing there if you're not used to doing this: mail4:~$ tar tzvf [...]/clamav-0.93.3.tar.gz | grep 'clamav-0.93.3/\(README\|INSTALL\)' -rw-r--r-- 1000/1000 73422 2008-07-07 18:38:08 clamav-0.93.3/README -rw-r--r-- 1000/1000 9416 2008-03-06 18:41:14 clamav-0.93.3/INSTALL Just extract the tarball to some convenient place beneath your home directory. Then there's quite a lot to read in the docs directory: mail4:~$ ls -l [...]/clamav-0.93.3/docs/*pdf total 2044 [snip] -rw-r--r-- 1 ged users 82058 2008-03-06 18:41 clamav-mirror-howto.pdf -rw-r--r-- 1 ged users 240788 2008-07-07 18:41 clamdoc.pdf -rw-r--r-- 1 ged users 102697 2008-03-06 18:41 phishsigs_howto.pdf -rw-r--r-- 1 ged users 27199 2008-04-02 21:17 signatures.pdf Plus more HTML than you can shake a stick at in the same place. -- 73, Ged. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
G.W. Haywood wrote: Currently, we accept all infected mail, and quietly quarantine it. May I suggest that you quarantine it, BUT STILL REJECT IT after it has been read (and recorded) in its entirety? No, please don't do that for viruses. If they are being transmitted by a real SMTP client, you'll generate annoying backscatter. You're making a rod for your own back if you accept bad mail. The sender will sell the recipients' addresses to all his spammer friends and you'll just get more of it. That is not true, in my experience. We see countless attempts by spammers to send to invalid addresses, years after those addresses cease to be valid. In my experience, spammers do not bother cleaning their address lists. It's so cheap to spam with a zombie network that the effort required to clean the list is not worth it. Regards, David. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
David F. Skoll wrote: G.W. Haywood wrote: Currently, we accept all infected mail, and quietly quarantine it. May I suggest that you quarantine it, BUT STILL REJECT IT after it has been read (and recorded) in its entirety? No, please don't do that for viruses. If they are being transmitted by a real SMTP client, you'll generate annoying backscatter. If done during the SMTP conversation the only thing that is going to see backscatter is the thing that sent it. Which really isn't backscatter. I am under the opinion that a message should never be silently blackholed. Steven ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
[EMAIL PROTECTED] wrote: If done during the SMTP conversation the only thing that is going to see backscatter is the thing that sent it. Which is why I qualified my reply with if the sending relay is a valid SMTP client. I am under the opinion that a message should never be silently blackholed. I used to share that opinion, but no longer do for viruses. If you turn off Clam's dubious Phishing options, the odds of a false-positive from Clam are very low. In that situation, there is no point in rejecting; it's better to silently discard. Regards, David. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
Hi all,
I need to open ports for Clamav database update, but since yesterday it
seems that IP address are changing every hour.. Can you guys please let
me know what should I do to resolve this issue.
Sending you ping output.
[EMAIL PROTECTED] root]# ping db.us.clamav.net
PING db.us.rr.clamav.net (199.184.215.2) 56(84) bytes of data.
--- db.us.rr.clamav.net ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2014ms
[EMAIL PROTECTED] root]# ping db.us.clamav.net
PING db.us.rr.clamav.net (208.67.80.27) 56(84) bytes of data.
--- db.us.rr.clamav.net ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4018ms
[EMAIL PROTECTED] root]# ping db.us.clamav.net
PING db.us.rr.clamav.net (64.142.100.50) 56(84) bytes of data.
--- db.us.rr.clamav.net ping statistics ---
7 packets transmitted, 0 received, 100% packet loss, time 6016ms
You have new mail in /var/spool/mail/root
Thanks,
Parveen
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David F.
Skoll
Sent: Thursday, August 07, 2008 2:28 PM
To: ClamAV users ML
Subject: Re: [Clamav-users] simplest replacement for ancient amavis-perl
jef moskot wrote:
I didn't mean to spark a milter fight, but as the Subject line says,
we're
looking for the simplest thing out there. I'm replacing a simplistic
perl
script that just broke a message down, clamscanned it, and either
passed
it on for delivery or quarantined and notified. That's it.
Here is a complete MIMEDefang filter to do just that:
#=
$Features{'Virus:CLAMD'} = '/full/path/to/clamd';
$ClamdSock = '/full/path/to/clamd.sock';
$Features{'Virus:CLAMAV'} = '/full/path/to/clamscan'
$AdminAddress = '[EMAIL PROTECTED]';
sub filter_end
{
my ($code, $category, $action) = message_contains_virus();
if ($action eq 'quarantine') {
send_quarantine_notifications();
action_discard();
}
}
#=
It'll quarantine the virus and sent a notification to $AdminAddress.
Regards,
David.
___
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://www.clamav.net/support/ml
**
This email may contain proprietary and confidential information and is sent for
the intended recipient(s) only. If by an addressing or transmission error this
email has been delivered to you, you are requested to delete it immediately.
You are also hereby notified that any use, any form of reproduction,
dissemination, copying, disclosure, modification, distribution and/or
publication of this e-mail message, contents or its attachment(s) other than by
its intended recipient(s) is strictly prohibited. All rights reserved
ikaSystems CorporationR.
___
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
On Fri, Aug 08, 2008 at 03:20:01PM CEST, [EMAIL PROTECTED] said: David F. Skoll wrote: G.W. Haywood wrote: Currently, we accept all infected mail, and quietly quarantine it. May I suggest that you quarantine it, BUT STILL REJECT IT after it has been read (and recorded) in its entirety? No, please don't do that for viruses. If they are being transmitted by a real SMTP client, you'll generate annoying backscatter. If done during the SMTP conversation the only thing that is going to see backscatter is the thing that sent it. Which really isn't backscatter. I am under the opinion that a message should never be silently blackholed. This mean your MTA must call clamav after the DATA end, but before answering it. -- Erwan ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
On Fri, Aug 08, 2008 at 09:25:19AM -0400, David F. Skoll wrote: I am under the opinion that a message should never be silently blackholed. I used to share that opinion, but no longer do for viruses. If you turn off Clam's dubious Phishing options, the odds of a false-positive from Clam are very low. In that situation, there is no point in rejecting; it's better to silently discard. I agree with David: it's better to discard a virus, than reject it just because the sending server has a slightly worse virus scanner, or hasn't received the signature updates yet. But I'm more paranoid: We only discard when _2_ independant scanners say it's a virus. Otherwise, we used to tempfail, but nowadays it's not worth the bother, and we just reject for single virus scanner hits. That's a measly few percent of the already insignificant amount of email viruses (we don't count phishes as a virus, they add to the score in SA). -- Jan-Pieter Cornet [EMAIL PROTECTED] !! Disclamer: The addressee of this email is not the intended recipient. !! !! This is only a test of the echelon and data retention systems. Please !! !! archive this message indefinitely to allow verification of the logs. !! ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
David F. Skoll wrote: [EMAIL PROTECTED] wrote: If done during the SMTP conversation the only thing that is going to see backscatter is the thing that sent it. Which is why I qualified my reply with if the sending relay is a valid SMTP client. Maybe we are just arguing semantics but anything that connects to my mail server and speaks RFC821 is valid. I might not like what it feeds me but that is what ClamAV/SpamAssassin is for. :) I am under the opinion that a message should never be silently blackholed. I used to share that opinion, but no longer do for viruses. If you turn off Clam's dubious Phishing options, the odds of a false-positive from Clam are very low. In that situation, there is no point in rejecting; it's better to silently discard. Returning a 5xx message is neither hard or resource intensive. Then even in the unlikely event of a false positive the sender knows. Steven ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
On Fri, 8 Aug 2008 13:31:24 +0100 (BST) G.W. Haywood [EMAIL PROTECTED] wrote: Currently, we accept all infected mail, and quietly quarantine it. May I suggest that you quarantine it, BUT STILL REJECT IT after it has been read (and recorded) in its entirety? You're making a rod for your own back if you accept bad mail. The sender will sell the recipients' addresses to all his spammer friends and you'll just get more of it. Unless I am incorrectly interpreting this, you are implying that he can accept the mail and then reject it later. That would cause 'backscatter' that will inevitable end up getting him blacklisted. -- Gerard [EMAIL PROTECTED] Marriage is the waste-paper basket of the emotions. signature.asc Description: PGP signature ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
Parveen Malik wrote: Hi all, I need to open ports for Clamav database update, but since yesterday it seems that IP address are changing every hour.. Can you guys please let me know what should I do to resolve this issue. Sending you ping output. [EMAIL PROTECTED] root]# ping db.us.clamav.net PING db.us.rr.clamav.net (199.184.215.2) 56(84) bytes of data. --- db.us.rr.clamav.net ping statistics --- 3 packets transmitted, 0 received, 100% packet loss, time 2014ms [EMAIL PROTECTED] root]# ping db.us.clamav.net PING db.us.rr.clamav.net (208.67.80.27) 56(84) bytes of data. --- db.us.rr.clamav.net ping statistics --- 5 packets transmitted, 0 received, 100% packet loss, time 4018ms [EMAIL PROTECTED] root]# ping db.us.clamav.net PING db.us.rr.clamav.net (64.142.100.50) 56(84) bytes of data. --- db.us.rr.clamav.net ping statistics --- 7 packets transmitted, 0 received, 100% packet loss, time 6016ms Can't you just have your firewall keep state on all outgoing connections? Steven ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
[EMAIL PROTECTED] wrote: Which is why I qualified my reply with if the sending relay is a valid SMTP client. Maybe we are just arguing semantics but anything that connects to my mail server and speaks RFC821 is valid. I might not like what it feeds me but that is what ClamAV/SpamAssassin is for. :) OK, let me be precise: By valid SMTP client, I mean one that generates a DSN in response to a 5xx status code. Returning a 5xx message is neither hard or resource intensive. I'm not arguing that. I'm just disagreeing with the statement that it's a good idea. Then even in the unlikely event of a false positive the sender knows. This is so unlikely that the backscatter risk outweighs the benefit. Regards, David. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
On Fri, 8 Aug 2008, David F. Skoll wrote: G.W. Haywood wrote: You're making a rod for your own back if you accept bad mail. The sender will sell the recipients' addresses to all his spammer friends and you'll just get more of it. In my experience, spammers do not bother cleaning their address lists. My thought process has been that if we give feedback as to which messages made it past our defenses, we're essentially telling the spammers how to construct better spam. Then again, maybe no one is there to see the 550s these days and since (I agree with David) spammers don't seem to care if addresses are valid, they probably don't care if the spam gets there or not. As for why we quarantine in the first place, we roll our own clam signatures, some of which are a little dicey, so we like to be able to dig ourselves out of the problems we create for ourselves. As long as the volume isn't out of control (it isn't yet), it's better for us to accept the responsibility than to place it on the users who somehow managed to construct sentences that read like Mab Libs but are nonetheless valid. Perhaps clam is the wrong tool for that kind of thing, but it's just so convenient, that it's going to be hard to choose another method. Jeffrey Moskot System Administrator [EMAIL PROTECTED] ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
David F. Skoll wrote: [EMAIL PROTECTED] wrote: Which is why I qualified my reply with if the sending relay is a valid SMTP client. Maybe we are just arguing semantics but anything that connects to my mail server and speaks RFC821 is valid. I might not like what it feeds me but that is what ClamAV/SpamAssassin is for. :) OK, let me be precise: By valid SMTP client, I mean one that generates a DSN in response to a 5xx status code. Fair enough. Then even in the unlikely event of a false positive the sender knows. This is so unlikely that the backscatter risk outweighs the benefit. I have had it happen. When messages mysteriously go missing and people call me asking where it went I can be rest assured saying that if something was rejected somewhere they should have received a bounce. It makes things easier to debug when there is feedback. What backscatter? If done at SMTP the only person that should be notified is the sender. If that sender goes and does something stupid with my rejection then that is the senders problem. Otherwise there is zero backscatter. Steven ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
[EMAIL PROTECTED] wrote: [...] What backscatter? If done at SMTP the only person that should be notified is the sender. I see. And it's impossible for a virus to forge MAIL FROM:, is it? Regards, David. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
Steven, I have a secured environment which governed by HIPAA regulatory, so I can't keep open everything. Thanks, Parveen -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, August 08, 2008 9:56 AM To: ClamAV users ML Subject: Re: [Clamav-users] simplest replacement for ancient amavis-perl Parveen Malik wrote: Hi all, I need to open ports for Clamav database update, but since yesterday it seems that IP address are changing every hour.. Can you guys please let me know what should I do to resolve this issue. Sending you ping output. [EMAIL PROTECTED] root]# ping db.us.clamav.net PING db.us.rr.clamav.net (199.184.215.2) 56(84) bytes of data. --- db.us.rr.clamav.net ping statistics --- 3 packets transmitted, 0 received, 100% packet loss, time 2014ms [EMAIL PROTECTED] root]# ping db.us.clamav.net PING db.us.rr.clamav.net (208.67.80.27) 56(84) bytes of data. --- db.us.rr.clamav.net ping statistics --- 5 packets transmitted, 0 received, 100% packet loss, time 4018ms [EMAIL PROTECTED] root]# ping db.us.clamav.net PING db.us.rr.clamav.net (64.142.100.50) 56(84) bytes of data. --- db.us.rr.clamav.net ping statistics --- 7 packets transmitted, 0 received, 100% packet loss, time 6016ms Can't you just have your firewall keep state on all outgoing connections? Steven ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml ** This email may contain proprietary and confidential information and is sent for the intended recipient(s) only. If by an addressing or transmission error this email has been delivered to you, you are requested to delete it immediately. You are also hereby notified that any use, any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message, contents or its attachment(s) other than by its intended recipient(s) is strictly prohibited. All rights reserved ikaSystems CorporationR. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
[EMAIL PROTECTED] wrote: No, is is trivial for anyone to forge mail from headers but that is irrelevant when virus filtering is done at the SMTP level. You don't send the rejection to the address in the mail from. You send the rejection to the server/client that sent you the message because the SMTP conversation is still going on and you know exactly who is trying to feed it to you. :-) I see. So you actually do believe it's impossible to forge SMTP envelope information? See, I have this bridge for sale... Regards, David. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
David F. Skoll wrote: [EMAIL PROTECTED] wrote: No, is is trivial for anyone to forge mail from headers but that is irrelevant when virus filtering is done at the SMTP level. You don't send the rejection to the address in the mail from. You send the rejection to the server/client that sent you the message because the SMTP conversation is still going on and you know exactly who is trying to feed it to you. :-) I see. So you actually do believe it's impossible to forge SMTP envelope information? See, I have this bridge for sale... No, I did not say that. I said it was trivial. I am just pointing out that it is irrelevant while the SMTP conversation is still going on. It is impossible(mostly) to forge the IP the message is being sent from if there is a live SMTP conversation going on and while that conversation is going on you know exactly what is sending you the garbage and you know exactly what to tell you don't want it. There is zero backscatter. Steven ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
[EMAIL PROTECTED] wrote: No, I did not say that. I said it was trivial. I am just pointing out that it is irrelevant while the SMTP conversation is still going on. It is impossible(mostly) to forge the IP the message is being sent from if there is a live SMTP conversation going on and while that conversation is going on you know exactly what is sending you the garbage and you know exactly what to tell you don't want it. There is zero backscatter. You obviously misunderstand SMTP. Please reread RFC 2821 and 2822. If you have further questions, let's take them off-list because this thread is likely boring to SMTP veterans. Regards, David. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
David F. Skoll wrote: [EMAIL PROTECTED] wrote: No, I did not say that. I said it was trivial. I am just pointing out that it is irrelevant while the SMTP conversation is still going on. It is impossible(mostly) to forge the IP the message is being sent from if there is a live SMTP conversation going on and while that conversation is going on you know exactly what is sending you the garbage and you know exactly what to tell you don't want it. There is zero backscatter. You obviously misunderstand SMTP. Please reread RFC 2821 and 2822. If you have further questions, let's take them off-list because this thread is likely boring to SMTP veterans. No need to be condescending about it. I have no problem taking it off list and explaining how you are mistaken. Steven ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
[EMAIL PROTECTED] wrote: No need to be condescending about it. I have no problem taking it off list and explaining how you are mistaken. OK, look. I guess I need to spell it out for you. End-user PC has virus. Virus does this: telnet isps-smtp-server 25 HELO bogus MAIL FROM:[EMAIL PROTECTED] RCPT TO:[EMAIL PROTECTED] DATA . Then ISP's mail server does this: telnet victims-smtp-server 25 HELO isps-smtp-server MAIL FROM:[EMAIL PROTECTED] RCPT TO:[EMAIL PROTECTED] DATA . If victim's SMTP server fails the DATA with a 5xx code, then backscatter goes [EMAIL PROTECTED] Understand now? Regards, David. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
David F. Skoll wrote: [EMAIL PROTECTED] wrote: No need to be condescending about it. I have no problem taking it off list and explaining how you are mistaken. OK, look. I guess I need to spell it out for you. End-user PC has virus. Virus does this: telnet isps-smtp-server 25 HELO bogus MAIL FROM:[EMAIL PROTECTED] RCPT TO:[EMAIL PROTECTED] DATA . Then ISP's mail server does this: telnet victims-smtp-server 25 HELO isps-smtp-server MAIL FROM:[EMAIL PROTECTED] RCPT TO:[EMAIL PROTECTED] DATA . If victim's SMTP server fails the DATA with a 5xx code, then backscatter goes [EMAIL PROTECTED] Understand now? I understand that but it is not my problem what the ISP's mail server does with it after I send a 5xx. It is the ISP's problem. I don't need random ISP's making their problems my problems. If anything it encourages the ISP to virus filter their users and take care of abuse problems rather then silently sweeping them under the rug. Steven ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
David F. Skoll writes: [EMAIL PROTECTED] wrote: i'm far from an expert but at some level i believe that you're both right. the real question boils down (i think) to who is trying to deliver this piece of unwanted email? if it's a Real MTA, then kicking back a 550 will -- probably -- have the MTA trying to return the message to the sender. there will probably be backscatter. if it's NOT a real MTA -- if it's a spam proxy or a virus trying to send the message -- then kicking back a 550 will -- probably -- have the message dropped on the floor. there will probably not be backscatter. so i think you're both right, more or less. rp rick pim [EMAIL PROTECTED] information technology services (613) 533-2242 queen's university, kingston --- Hmm hmm hmmm Reality stinks. That's why I try to improve on it whenever I can. -- The Flash (TV) ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
rick pim wrote: David F. Skoll writes: [EMAIL PROTECTED] wrote: i'm far from an expert but at some level i believe that you're both right. the real question boils down (i think) to who is trying to deliver this piece of unwanted email? if it's a Real MTA, then kicking back a 550 will -- probably -- have the MTA trying to return the message to the sender. there will probably be backscatter. if it's NOT a real MTA -- if it's a spam proxy or a virus trying to send the message -- then kicking back a 550 will -- probably -- have the message dropped on the floor. there will probably not be backscatter. so i think you're both right, more or less. I think you are right. Sending a 5xx and silently quarantining both have their advantages and disadvantages. Who can say whether one is better than the other. Steven ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
David F. Skoll schrieb: OK, look. I guess I need to spell it out for you. End-user PC has virus. Virus does this: telnet isps-smtp-server 25 In my experience that's very unusual behaviour for a virus. The vast majority try to connect directly to the recipient's MX. -- Tilman Schmidt Phoenix Software GmbH Bonn, Germany signature.asc Description: OpenPGP digital signature ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
On Fri, 8 Aug 2008 11:20:54 -0400 rick pim [EMAIL PROTECTED] wrote: David F. Skoll writes: [EMAIL PROTECTED] wrote: i'm far from an expert but at some level i believe that you're both right. the real question boils down (i think) to who is trying to deliver this piece of unwanted email? if it's a Real MTA, then kicking back a 550 will -- probably -- have the MTA trying to return the message to the sender. there will probably be backscatter. if it's NOT a real MTA -- if it's a spam proxy or a virus trying to send the message -- then kicking back a 550 will -- probably -- have the message dropped on the floor. there will probably not be backscatter. so i think you're both right, more or less. Employing 'greylisting' would vastly improve the chances of eliminating the acceptance of SPAM at the MTA level. -- Gerard [EMAIL PROTECTED] The tree of research must from time to time be refreshed with the blood of bean counters. Alan Kay signature.asc Description: PGP signature ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
David F. Skoll wrote: [EMAIL PROTECTED] wrote: [...] What backscatter? If done at SMTP the only person that should be notified is the sender. I see. And it's impossible for a virus to forge MAIL FROM:, is it? That is the concern of the connecting system - they will suffer any consequences of accepting the responsibility of forwarding bad mail and I really don't care if that happens. dp ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
David F. Skoll wrote: [EMAIL PROTECTED] wrote: No need to be condescending about it. I have no problem taking it off list and explaining how you are mistaken. OK, look. I guess I need to spell it out for you. End-user PC has virus. Virus does this: telnet isps-smtp-server 25 HELO bogus MAIL FROM:[EMAIL PROTECTED] RCPT TO:[EMAIL PROTECTED] DATA . Then ISP's mail server does this: telnet victims-smtp-server 25 HELO isps-smtp-server MAIL FROM:[EMAIL PROTECTED] RCPT TO:[EMAIL PROTECTED] DATA . If victim's SMTP server fails the DATA with a 5xx code, then backscatter goes [EMAIL PROTECTED] Understand now? Sounds like the isps-smtp-server operator has a problem of accepting responsibility to forward mail that may be undeliverable. dp ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
Gerard writes: Employing 'greylisting' would vastly improve the chances of eliminating the acceptance of SPAM at the MTA level. it certainly does. unfortunately, in practice, one of the prime advantages of greylisting -- the fact that it will never block 'real' mail -- turns out, um, not to be true. there are so many standards-noncompliant MTAs out there that greylisting does block real mail. (this is one of the things that makes me crazy.) (we still use it, of course.) rp rick pim [EMAIL PROTECTED] information technology services (613) 533-2242 queen's university, kingston --- You call this a *trial*?! This is nothing but a *kangaroo* *court* without the hoppy, furry guy! -- The Flash (TV) ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
On Fri, 8 Aug 2008 [EMAIL PROTECTED] wrote: telnet isps-server 25 ... HELO bogus ... MAIL FROM:[EMAIL PROTECTED] telnet victims-server 25 ... HELO isps-server ... MAIL FROM If victim's SMTP server fails the DATA with a 5xx code, then backscatter goes [EMAIL PROTECTED] it is not my problem what the ISP's mail server does with it after I send a 5xx. Well, first of all, yes it IS. It's *everyone's* problem. That forged address could be on *your* server, and *you* get the backscatter from some other victim system that also doesn't care what the ISP does with it... That being said, I agree that the number of viruses that still try to find and use an infected PC's SMTP server is very small... In which case the odds of hitting a false positive via a mail relay are greater than hitting a virus via a mail relay. Now that you make me think about it, the only time I ever see backscatter from a virus is when someone uses a virus checker that generates its own DSN rather than issue SMTP 5xx rejections. I am so *very* glad that ClamAV is just a *reporting* tool! :) If anything it encourages the ISP to virus filter their users and take care of abuse problems rather then silently sweeping them under the rug. Begging pardon, but just because someone uses a standard postfix config and follows the standard 'recommended' practice of listing dial-up IP's as 'trusted clients' does not mean they are 'sweeping' anything under their 'rug'. It is just a choice made to minimize the performance hit of scanning and filtering mail that is 99.99+% valid. BUT this practice of not scanning mail from trusted clients is only 'safe' if virus checking is done post-SMTP, in procmail. Otherwise, there is the risk that mail from one user of a system to another will not be virus checked at *all*, permitting the spread of viruses within a given user base. So my closing thought is that I will want to do two things with my new Mail Avenger setup: 1) I will want to run clamav on *all* messages, regardless of source. This will prevent intra-system viruses and also cut down on backscatter by preventing my server from relaying an outgoing virus. 2) I will want to check in procmail to see whether an intra-system message passed through my SMTP or was directly delivered via LDA, and in the latter case I will need to run clamav from procmail. So thank you all, for stirring up some good serious thoughts! - Charles, HWCN ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
Tilman Schmidt wrote: telnet isps-smtp-server 25 In my experience that's very unusual behaviour for a virus. The vast majority try to connect directly to the recipient's MX. I see both. I see malware that connects directly from end-user PCs, and more sophisticated malware that actually breaks CAPTCHAs on Hotmail/GMail/etc. and sends via those services. I've also seen malware that checks the user's Outlook settings and sends via the configured SMTP server (though that case is admittedly the rarest.) Regards, David. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
On Fri, 8 Aug 2008, Charles Gregory wrote: Well, first of all, yes it IS. It's *everyone's* problem. That forged address could be on *your* server, and *you* get the backscatter from some other victim system that also doesn't care what the ISP does with it... what he said: we have two accounts/addresses that get, between them, about 200,000 bounces a day; this has been going on for something more than 8 months. (that said, there's something to be said for bouncing mail: one of our vendors is occasionally silently blocking my email to them. clearly SOMETHING about my messages are triggering their spam filters. it sure would be nice if i got the bounces for those) rp ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
rick pim wrote: (that said, there's something to be said for bouncing mail: one of our vendors is occasionally silently blocking my email to them. clearly SOMETHING about my messages are triggering their spam filters. it sure would be nice if i got the bounces for those) I discard viruses, but reject (with 5xx) spam, because spam-detectors have a much higher false-positive rate than virus-detectors. Regards, David ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
Charles Gregory wrote: On Fri, 8 Aug 2008 [EMAIL PROTECTED] wrote: telnet isps-server 25 ... HELO bogus ... MAIL FROM:[EMAIL PROTECTED] telnet victims-server 25 ... HELO isps-server ... MAIL FROM If victim's SMTP server fails the DATA with a 5xx code, then backscatter goes [EMAIL PROTECTED] it is not my problem what the ISP's mail server does with it after I send a 5xx. Well, first of all, yes it IS. It's *everyone's* problem. That forged address could be on *your* server, and *you* get the backscatter from some other victim system that also doesn't care what the ISP does with it... Heh, everyone is entitled to their opinion. Mine just happens to differ from yours. I have been at the other end of backscatter and it is by no means fun but when it happens I am fully capable of taking measures against as I would any other spam/virus source. This is where RBLs come in handy. If anything it encourages the ISP to virus filter their users and take care of abuse problems rather then silently sweeping them under the rug. Begging pardon, but just because someone uses a standard postfix config and follows the standard 'recommended' practice of listing dial-up IP's as 'trusted clients' does not mean they are 'sweeping' anything under their 'rug'. It is just a choice made to minimize the performance hit of scanning and filtering mail that is 99.99+% valid. I meant to imply that when the ISP does not virus filter and the recipient silently drops the message the problem never gets resolved because nobody is made aware of it. The ISP customer will continue to be infected and continue to send out garbage. I suppose this is all based on the assumption that the ISP even cares. Cause as everyone knows *all* ISPs care. Right? ;) So thank you all, for stirring up some good serious thoughts! It has been entertaining. Steven ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
rick pim wrote: On Fri, 8 Aug 2008, Charles Gregory wrote: Well, first of all, yes it IS. It's *everyone's* problem. That forged address could be on *your* server, and *you* get the backscatter from some other victim system that also doesn't care what the ISP does with it... what he said: we have two accounts/addresses that get, between them, about 200,000 bounces a day; this has been going on for something more than 8 months. If the bulk of thoses is coming from infected PC's there is no harm in rejecting them with a 5xx - the PC is going to ignore that anyway - it is certainly not going to bounce the message back to the sender. If it is coming from a legitimate system it would be useful to provide feedback to that system's operator that they are handling dirty mail. In that case a 5xx error is appropriate. If they then bounce the message to some unsuspecting victim then they will get additional feedback. I don't see where dropping those messages is helpful but do see all manor of advantages of rejecting with 5xx. My 5xx rejects, which are in the thousands, are 10 to one generated by DNSBL or dictionary attempts (user unknown), not ClamAV hits. (that said, there's something to be said for bouncing mail: one of our vendors is occasionally silently blocking my email to them. clearly SOMETHING about my messages are triggering their spam filters. it sure would be nice if i got the bounces for those) Can't have it both ways - although you could ask to be whitelisted. I do that for all our regular customers and contacts, and also whitelist any mail lists our users are on. I'm very happy to expect connecting systems to be well run or to suffer the consequences. In fact I feel that way about my systems. If I make a mistake I expect to pay for it. dp ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
Charles Gregory wrote: On Fri, 8 Aug 2008 [EMAIL PROTECTED] wrote: telnet isps-server 25 ... HELO bogus ... MAIL FROM:[EMAIL PROTECTED] telnet victims-server 25 ... HELO isps-server ... MAIL FROM If victim's SMTP server fails the DATA with a 5xx code, then backscatter goes [EMAIL PROTECTED] it is not my problem what the ISP's mail server does with it after I send a 5xx. Well, first of all, yes it IS. It's *everyone's* problem. That forged address could be on *your* server, and *you* get the backscatter from some other victim system that also doesn't care what the ISP does with it... That being said, I agree that the number of viruses that still try to find and use an infected PC's SMTP server is very small... In which case the odds of hitting a false positive via a mail relay are greater than hitting a virus via a mail relay. Now that you make me think about it, the only time I ever see backscatter from a virus is when someone uses a virus checker that generates its own DSN rather than issue SMTP 5xx rejections. I am so *very* glad that ClamAV is just a *reporting* tool! :) If anything it encourages the ISP to virus filter their users and take care of abuse problems rather then silently sweeping them under the rug. Begging pardon, but just because someone uses a standard postfix config and follows the standard 'recommended' practice of listing dial-up IP's as 'trusted clients' does not mean they are 'sweeping' anything under their 'rug'. It is just a choice made to minimize the performance hit of scanning and filtering mail that is 99.99+% valid. BUT this practice of not scanning mail from trusted clients is only 'safe' if virus checking is done post-SMTP, in procmail. Otherwise, there is the risk that mail from one user of a system to another will not be virus checked at *all*, permitting the spread of viruses within a given user base. So my closing thought is that I will want to do two things with my new Mail Avenger setup: 1) I will want to run clamav on *all* messages, regardless of source. This will prevent intra-system viruses and also cut down on backscatter by preventing my server from relaying an outgoing virus. 2) I will want to check in procmail to see whether an intra-system message passed through my SMTP or was directly delivered via LDA, and in the latter case I will need to run clamav from procmail. So thank you all, for stirring up some good serious thoughts! - Charles, HWCN ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
[EMAIL PROTECTED] wrote: Charles Gregory wrote: On Fri, 8 Aug 2008 [EMAIL PROTECTED] wrote: telnet isps-server 25 ... HELO bogus ... MAIL FROM:[EMAIL PROTECTED] telnet victims-server 25 ... HELO isps-server ... MAIL FROM If victim's SMTP server fails the DATA with a 5xx code, then backscatter goes [EMAIL PROTECTED] it is not my problem what the ISP's mail server does with it after I send a 5xx. Well, first of all, yes it IS. It's *everyone's* problem. That forged address could be on *your* server, and *you* get the backscatter from some other victim system that also doesn't care what the ISP does with it... That being said, I agree that the number of viruses that still try to find and use an infected PC's SMTP server is very small... In which case the odds of hitting a false positive via a mail relay are greater than hitting a virus via a mail relay. Now that you make me think about it, the only time I ever see backscatter from a virus is when someone uses a virus checker that generates its own DSN rather than issue SMTP 5xx rejections. I am so *very* glad that ClamAV is just a *reporting* tool! :) If anything it encourages the ISP to virus filter their users and take care of abuse problems rather then silently sweeping them under the rug. Begging pardon, but just because someone uses a standard postfix config and follows the standard 'recommended' practice of listing dial-up IP's as 'trusted clients' does not mean they are 'sweeping' anything under their 'rug'. It is just a choice made to minimize the performance hit of scanning and filtering mail that is 99.99+% valid. BUT this practice of not scanning mail from trusted clients is only 'safe' if virus checking is done post-SMTP, in procmail. Otherwise, there is the risk that mail from one user of a system to another will not be virus checked at *all*, permitting the spread of viruses within a given user base. So my closing thought is that I will want to do two things with my new Mail Avenger setup: 1) I will want to run clamav on *all* messages, regardless of source. This will prevent intra-system viruses and also cut down on backscatter by preventing my server from relaying an outgoing virus. 2) I will want to check in procmail to see whether an intra-system message passed through my SMTP or was directly delivered via LDA, and in the latter case I will need to run clamav from procmail. So thank you all, for stirring up some good serious thoughts! - Charles, HWCN Doh, sorry about this. To many windows open at the same time... Steven ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
[EMAIL PROTECTED] wrote: I meant to imply that when the ISP does not virus filter and the recipient silently drops the message the problem never gets resolved because nobody is made aware of it. The ISP customer will continue to be infected and continue to send out garbage. I suppose this is all based on the assumption that the ISP even cares. Cause as everyone knows *all* ISPs care. Right? ;) http://www.spam-site.com/isp-doing-business-with-spammers.shtml Oh, sure :) dp ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
[Clamav-users] simplest replacement for ancient amavis-perl
I've been using ClamAV happily for years, but we're finally moving to a modern server and our heavily modified amavis-perl script no longer works and is significantly difficult to debug that it makes sense to modernize. In the past, we've not dealt with clamd or any daemonized version of amavis, simply because we had the cycles to burn and there seemed to be no reason to use something that requires something else to babysit it, so despite years of experience with clam, I've never messed with clamd.conf and other such things. Currently, we accept all infected mail, and quietly quarantine it. We don't refuse it at SMTP connect, although I might be able to be convinced that that's a better idea. Still, I'd like to maintain the current behavior, since that's what everyone is used to. So, basically, all I need is a replacement for a perl script that throws a wad of text at clamscan and then either passes it on for normal delivery or stashes it away in a quarantine directory, with a note passed on to a local admin address in the latter case. Since amavis seems to have morphed into a monster with a million config options, links to SQL databases, and it's own separate milter that you need to run along with it(!), I was looking at clamav-milter, which looks simple and also comes with the benefit of a community I'm comfortable with. I can't find any decent documentation on it, however, (if I'm missing something obvious, please point me at it!) and it seems to jam mail at SMTP connection time rather than accepting and scanning later. I've found references to using it to quarantine messages, which would be perfect, but I haven't seen the docs to explain how to do that. Also I've found some explanations of how to compile clam to get the milter, but those were in connection with FreeBSD ports, and I don't like to have to wait until an update has been bundled before I can deploy it. Any advice would be welcome, including STFU and RTFM, as long as you can point me to a decent manual. Thanks! Jeffrey Moskot System Administrator [EMAIL PROTECTED] ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
On Thu, 7 Aug 2008 10:06:09 -0400 (EDT) jef moskot [EMAIL PROTECTED] wrote: [snip] Currently, we accept all infected mail, and quietly quarantine it. We don't refuse it at SMTP connect, although I might be able to be convinced that that's a better idea. Still, I'd like to maintain the current behavior, since that's what everyone is used to. Depending on the quantity of emails your receive, you might very well significantly reduce the load on your system by using one or perhaps a few RBL's. There is no point, at least in opinion, of accepting mail that is obviously SPAM. So, basically, all I need is a replacement for a perl script that throws a wad of text at clamscan and then either passes it on for normal delivery or stashes it away in a quarantine directory, with a note passed on to a local admin address in the latter case. Since amavis seems to have morphed into a monster with a million config options, links to SQL databases, and it's own separate milter that you need to run along with it(!), I was looking at clamav-milter, which looks simple and also comes with the benefit of a community I'm comfortable with. I can't find any decent documentation on it, however, (if I'm missing something obvious, please point me at it!) and it seems to jam mail at SMTP connection time rather than accepting and scanning later. I've found references to using it to quarantine messages, which would be perfect, but I haven't seen the docs to explain how to do that. Also I've found some explanations of how to compile clam to get the milter, but those were in connection with FreeBSD ports, and I don't like to have to wait until an update has been bundled before I can deploy it. The FreeBSD ports for ClamAV are usually up-to-date. Rarely is there more than a day or two lapse between the release of a new version and the release of it into the FBSD ports system. Using the ports system would also make updating your ClamAV installation far easier. Any advice would be welcome, including STFU and RTFM, as long as you can point me to a decent manual. Thanks! You did not mention your MTA. If it is Postfix, I think your might want to investigate something like clamsmtp since the ClamAV Milter does not work exactly like it does in Sendmail. It does work; however, a few of the options are not compatible. -- Gerard [EMAIL PROTECTED] Learning without thought is labor lost; thought without learning is perilous. Confucius signature.asc Description: PGP signature ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
On Thu, 7 Aug 2008, Gerard wrote: Depending on the quantity of emails your receive, you might very well significantly reduce the load on your system by using one or perhaps a few RBL's. There is no point, at least in opinion, of accepting mail that is obviously SPAM. We definitely do that already. It's insane not to do that these days. We use a lot of different signatures from different sources with Clam and there's enough doubt about some of them that quarantining is preferred, and it's definitely saved us a few times. The FreeBSD ports for ClamAV are usually up-to-date. Rarely is there more than a day or two lapse between the release of a new version and the release of it into the FBSD ports system. Using the ports system would also make updating your ClamAV installation far easier. It's pretty easy to compile from source, but I can see the appeal. The only reason I'm sort of interested in the port at this point is that it seems to do a certain amount of work for you if you want to use the milter...but I'm quite content to continue compiling on my own, if I can just figure out what I'm supposed to do the first time. And if clamav-milter is really what I want. If it's not, then I don't need to change my clammerings at all. You did not mention your MTA. Oops, sorry. We're married to sendmail at this point. Jeffrey Moskot System Administrator [EMAIL PROTECTED] ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
jef moskot wrote: So, basically, all I need is a replacement for a perl script that throws a wad of text at clamscan and then either passes it on for normal delivery or stashes it away in a quarantine directory, with a note passed on to a local admin address in the latter case. I recommend MIMEDefang. (Of course, I'm the author, so I would recommend it...) http://www.mimedefang.org/ It's not brain-dead simple, but it's pretty simple, and it has the nice feature of allowing you to code SMTP-time policy decisions in Perl. Regards, David. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
On Thu, Aug 7, 2008 at 16:40, David F. Skoll [EMAIL PROTECTED] wrote: I recommend MIMEDefang. (Of course, I'm the author, so I would recommend it...) I use both amavisd-new and MIMEDefang. Of those I'd recommend MD over amavisd-new. It's easy to customise the heck out of (I don't know perl and I can manage) and just works. The MD mailing list is also pretty helpful for those times when you discover that you're not so much in over your head, but you no longer know which way up is supposed to be ;) -- Rob MacGregor Whoever fights monsters should see to it that in the process he doesn't become a monster. Friedrich Nietzsche ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
So, basically, all I need is a replacement for a perl script that throws a wad of text at clamscan and then either passes it on for normal delivery or stashes it away in a quarantine directory, with a note passed on to a local admin address in the latter case. I'd also recommend MIMEDefang. I'm not the author, just some user. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
On Thu, 7 Aug 2008 11:36:32 -0400 (EDT) jef moskot [EMAIL PROTECTED] wrote: You did not mention your MTA. Oops, sorry. We're married to sendmail at this point. Would you entertain a divorce? IMHO, switching to Postfix might very well make your life easier. The configuration is far simpler and using amavis-new is not a problem. In fact, it is recommend by the author of himself. I assumed that you were referring to amavis-new and not the depreciated amavis program. ClamAV with amavis-new is a nice fit and works quite well. You can get all the support your need for the setup from the Postfix forum. Just my 2¢. -- Gerard [EMAIL PROTECTED] The second best policy is dishonesty. signature.asc Description: PGP signature ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
On Thu, Aug 07, 2008 at 04:46:48PM +0100, Rob MacGregor wrote: On Thu, Aug 7, 2008 at 16:40, David F. Skoll [EMAIL PROTECTED] wrote: I recommend MIMEDefang. (Of course, I'm the author, so I would recommend it...) I use both amavisd-new and MIMEDefang. Of those I'd recommend MD over amavisd-new. It's easy to customise the heck out of (I don't know perl and I can manage) and just works. I use both, but MD is IMO more of a hobbyist tool (you could consider it a bare-bones free version of CanIT, which David likes to sell). That's why I use it only on my personal server. You need lots of custom code to get for example all the nice amavisd-new features (penpals, bounce killer etc). So MD if you are able customize the heck out of it, or amavisd-new for a ready, robust, regularly enhanced tool. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
Henrik K wrote: I use both, but MD is IMO more of a hobbyist tool I would not characterize it like that. MIMEDefang is a framework; you have to implement your policy. So it's true that it doesn't ship with many pre-canned features like Amavis does, and does require more work on your part to craft your policy. On the other hand, it's certainly a ready, robust, regularly-enhanced tool that's used on extremely large sites, some of which process tens of millions of messages per day. Regards, David. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
jef moskot wrote:
I didn't mean to spark a milter fight, but as the Subject line says, we're
looking for the simplest thing out there. I'm replacing a simplistic perl
script that just broke a message down, clamscanned it, and either passed
it on for delivery or quarantined and notified. That's it.
Here is a complete MIMEDefang filter to do just that:
#=
$Features{'Virus:CLAMD'} = '/full/path/to/clamd';
$ClamdSock = '/full/path/to/clamd.sock';
$Features{'Virus:CLAMAV'} = '/full/path/to/clamscan'
$AdminAddress = '[EMAIL PROTECTED]';
sub filter_end
{
my ($code, $category, $action) = message_contains_virus();
if ($action eq 'quarantine') {
send_quarantine_notifications();
action_discard();
}
}
#=
It'll quarantine the virus and sent a notification to $AdminAddress.
Regards,
David.
___
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
Oops!! I forgot a line; sorry!
(I'll direct followups to MIMEDefang mailing list. This is somewhat OT.)
#=
$Features{'Virus:CLAMD'} = '/full/path/to/clamd';
$ClamdSock = '/full/path/to/clamd.sock';
$Features{'Virus:CLAMAV'} = '/full/path/to/clamscan'
$AdminAddress = '[EMAIL PROTECTED]';
sub filter_end
{
my ($code, $category, $action) = message_contains_virus();
if ($action eq 'quarantine') {
action_quarantine_entire_message(); # Forgot this in original post.
send_quarantine_notifications();
action_discard();
}
}
#=
___
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
On Thu, 7 Aug 2008 11:36:32 -0400 (EDT) jef moskot [EMAIL PROTECTED] wrote: You did not mention your MTA. Oops, sorry. We're married to sendmail at this point. In that case, why not just use clamav as a milter. It's been working fine for us for the last couple of years. Steve pgpKwAcXq2o3e.pgp Description: PGP signature ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
jef moskot wrote: On Thu, 7 Aug 2008, Henrik K wrote: I use both, but MD is IMO more of a hobbyist tool... I didn't mean to spark a milter fight, but as the Subject line says, we're looking for the simplest thing out there. I'm replacing a simplistic perl script that just broke a message down, clamscanned it, and either passed it on for delivery or quarantined and notified. That's it. If MIMEDefang is bare-bones, that actually sounds appealing. We're using a script that went EOL years ago, so we don't need state-of-the-art. Given our parameters, I'm still not sure if clamav-milter might be a quicker fix. But now that you've opened up the possibility of something initially simple with the ability to add complexity, I'm going to have to do some reading. If we're going to have to learn one new thing no matter what, maybe it should be something we can build on later. Thanks for the comments, guys, I'll be sure to report back. Try ClamSMTP http://memberwebs.com/stef/software/clamsmtp/ It's simple. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] simplest replacement for ancient amavis-perl
Gerard wrote: On Thu, 7 Aug 2008 11:36:32 -0400 (EDT) jef moskot [EMAIL PROTECTED] wrote: You did not mention your MTA. Oops, sorry. We're married to sendmail at this point. Would you entertain a divorce? IMHO, switching to Postfix might very well make your life easier. The configuration is far simpler It has been a long time since Postfix was simpler than Sendmail in any important way. They are now nearly equally complex as Postfix has become nearly as capable as Sendmail. When they are equally capable they will be equally complex. There's no free lunch. dp ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
