Jerry wrote:
> On Wed, 02 Dec 2009 01:33:51 -0500
> Michael Katz replied:
>
>> Responding to support lists is not a sales strategy, and if it was it
>> would be the worst strategy imaginable because it doesn't work. We
>> sell software because we have to make a living but answering on lists
>>
On Wed, 02 Dec 2009 01:33:51 -0500
Michael Katz replied:
>Responding to support lists is not a sales strategy, and if it was it
>would be the worst strategy imaginable because it doesn't work. We
>sell software because we have to make a living but answering on lists
>is more of a personality tr
Stan Hoeppner wrote:
Wietse Venema put forth on 11/30/2009 3:56 PM:
The cost of a modern plenty powerful (CPU/memory) 1U server with a
couple of fast sata disks is around $1000-2000, paid _once_ with no
recurring licensing fees as all the software is FOSS, with minimal power
usage, maybe $100/y
Wietse Venema put forth on 12/1/2009 6:17 PM:
> I would not be so quick to dismiss DNS-related problems out of hand
> in scenarios that involve synthetic email messages.
Ok, I follow you now Wietse. Given the inbound mail load he's
generating, the DNS resolvers in his test environment may not be
Stan Hoeppner:
> Wietse Venema put forth on 12/1/2009 3:47 PM:
>
> > Surely, mail is injected via SMTP, and therefore, the Postfix SMTP
> > server will attempt to lookup the client hostname and IP address;
> > since they are using SMTP-based content filters, that is another
> > source of name serv
Wietse Venema put forth on 12/1/2009 3:47 PM:
> Surely, mail is injected via SMTP, and therefore, the Postfix SMTP
> server will attempt to lookup the client hostname and IP address;
> since they are using SMTP-based content filters, that is another
> source of name service lookups. All this pres
Stan Hoeppner:
> Wietse Venema put forth on 12/1/2009 1:20 PM:
>
> > If your performance is inadequate, I suggest that you do a detailed
> > system performance analysis to find out if the limit is CPU, memory,
> > file I/O or perhaps some trivial DNS configuration problem.
>
> That may be difficu
Wietse Venema put forth on 12/1/2009 1:20 PM:
> If your performance is inadequate, I suggest that you do a detailed
> system performance analysis to find out if the limit is CPU, memory,
> file I/O or perhaps some trivial DNS configuration problem.
That may be difficult for the OP to provide. Fr
Wietse,
Thanks for all these useful points. I will inform the list about the results
of our tests regarding the issue.
Warm Regards
Ali Majdzadeh Kohbanani
2009/12/1 Wietse Venema
> Ali Majdzadeh:
> > Wietse,
> > Hi
> > Thanks for your reply. I recall that I had read about another filtering
> >
Ali Majdzadeh:
> Wietse,
> Hi
> Thanks for your reply. I recall that I had read about another filtering
> option available in Postfix which was called smtpd_proxy_filter (if I spell
> it correctly) and which filtered messages before queuing. So, is there any
> difference between the so-called metho
Wietse,
Hi
Thanks for your reply. I recall that I had read about another filtering
option available in Postfix which was called smtpd_proxy_filter (if I spell
it correctly) and which filtered messages before queuing. So, is there any
difference between the so-called method and using Milter?
Thanks
Ali Majdzadeh:
> question concerning what Wietse proposed. Does the usage of milter help? I
> mean, is the milter architecture considered as a way to kill spam load
> _before_ piping inbound connections to AS/AV content filter daemons? Or,
Milter is a way to inspect or update message content witho
Stan,
Thank you a lot for all these valuable information. Your reply proved that
there exists some circumstances where nothing can help but experience.
Thanks again.
Regarding the points which had mentioned in your mail, I would like to ask a
question concerning what Wietse proposed. Does the usage
Ali Majdzadeh put forth on 12/1/2009 12:25 AM:
> Dear friends,
> Thanks for this nice discussion. Actually, as a project, we are going to
> deliver an e-mail architecture which supports over 100 users. We use
> Postfix, courier-imap, amavisd-new, spamassassin and clamav and of
> course the tool
On 12/1/2009, Ali Majdzadeh (ali.majdza...@gmail.com) wrote:
> We use Postfix, courier-imap,
Highly recommend you use dovecot instead of courier-imap - dovecot is
*much* faster and more robust, and getting better every day.
Dear friends,
Thanks for this nice discussion. Actually, as a project, we are going to
deliver an e-mail architecture which supports over 100 users. We use
Postfix, courier-imap, amavisd-new, spamassassin and clamav and of course
the tools needed to balance the load between multiple instances o
On 11/30/2009 3:11 AM, Ali Majdzadeh wrote:
Stan, Hi Thanks for your detailed response. Actually, the main reason
which drove us toward performing virus scanning as an offline process
was performance. As we deal with large amounts of e-mails, we found
the way amavisd-new or other filtering manage
Wietse Venema put forth on 11/30/2009 3:56 PM:
>> The cost of a modern plenty powerful (CPU/memory) 1U server with a
>> couple of fast sata disks is around $1000-2000, paid _once_ with no
>> recurring licensing fees as all the software is FOSS, with minimal power
>> usage, maybe $100/year. What's
Michael Katz a écrit :
> Stan Hoeppner wrote:
>> Eero Volotinen put forth on 11/30/2009 2:14 AM:
>>> Quoting Ali Majdzadeh :
>>>
Stan,
Hi
Thanks for your detailed response. Actually, the main reason which
drove us
toward performing virus scanning as an offline process was
>
Stan Hoeppner:
> Michael Katz put forth on 11/30/2009 2:45 PM:
>
> > There are many filtering Postfix AV solutions that are far more
> > efficient than Amavisd and many AV scanners that are considerably more
> > scalable than clamav such. A few years ago we did some detailed testing
> > between C
Eero Volotinen put forth on 11/30/2009 2:59 PM:
> Michael Katz wrote:
>
>> There are many filtering Postfix AV solutions that are far more
>> efficient than Amavisd and many AV scanners that are considerably more
>> scalable than clamav such. A few years ago we did some detailed
>> testing betwee
Michael Katz put forth on 11/30/2009 2:45 PM:
> There are many filtering Postfix AV solutions that are far more
> efficient than Amavisd and many AV scanners that are considerably more
> scalable than clamav such. A few years ago we did some detailed testing
> between ClamAV and commercial av sca
Michael Katz wrote:
There are many filtering Postfix AV solutions that are far more
efficient than Amavisd and many AV scanners that are considerably more
scalable than clamav such. A few years ago we did some detailed testing
between ClamAV and commercial av scanners and the difference was h
Stan Hoeppner wrote:
Eero Volotinen put forth on 11/30/2009 2:14 AM:
Quoting Ali Majdzadeh :
Stan,
Hi
Thanks for your detailed response. Actually, the main reason which
drove us
toward performing virus scanning as an offline process was
performance. As
we deal with large amounts of e-mails, we
Eero Volotinen put forth on 11/30/2009 2:14 AM:
> Quoting Ali Majdzadeh :
>
>> Stan,
>> Hi
>> Thanks for your detailed response. Actually, the main reason which
>> drove us
>> toward performing virus scanning as an offline process was
>> performance. As
>> we deal with large amounts of e-mails, we
Quoting Ali Majdzadeh :
Stan,
Hi
Thanks for your detailed response. Actually, the main reason which drove us
toward performing virus scanning as an offline process was performance. As
we deal with large amounts of e-mails, we found the way amavisd-new or other
filtering management tools performi
Stan,
Hi
Thanks for your detailed response. Actually, the main reason which drove us
toward performing virus scanning as an offline process was performance. As
we deal with large amounts of e-mails, we found the way amavisd-new or other
filtering management tools performing filtering too slow. We i
Ali Majdzadeh put forth on 11/30/2009 12:28 AM:
> Hello all,
> I do not know whether here is the right place to ask this question or
> not, but I would like to know if it is a good idea to perform offline
> e-mail virus scanning. By offline, I mean a scenario in which e-mail
> filtering management
Hi,
You shouldn't never try to use amavisd that way. Just configure it as
content filter option in main.cf or build recipient access maps invoking
it with filter action and just do after queue scans.
Bye!
> Egoitz,
> Hi
> Thanks for your mail. I have used amavisd-new but unfortunately it can not
Egoitz,
Hi
Thanks for your mail. I have used amavisd-new but unfortunately it can not
handle e-mail scanning in offline mode.
Anyway, thanks a lot.
Kind Regards
Ali Majdzadeh Kohbanani
2009/11/30
> Hi Ali,
>
> The scenario you're describing is not a good idea because you don't know
> when you'r
Hi Ali,
The scenario you're describing is not a good idea because you don't know
when you're users are going to check they're mail accounts. If you want a
scalable email checking system and after queue for avoiding slow responses
from you're smtpd daemons try amavisd-new.
Bye!!
> Hello all,
> I
Hello all,
I do not know whether here is the right place to ask this question or not,
but I would like to know if it is a good idea to perform offline e-mail
virus scanning. By offline, I mean a scenario in which e-mail filtering
management tools (like amavisd-new) do not hand out received e-mails
32 matches
Mail list logo
