Hello all,
About a year ago I set up a mail server on CentOS using this howto: http://wanderingbarque.com/howtos/mailserver/mailserver.html I managed to add amavisd-new with clamav and spamassassin. It runs very well, but it runs on CentOS 5.2, and if I try to upgrade, amavisd-new and clamav break. we are now also at the point where a backup mx will need to be implemented.
If necessary I am willing to implement a new mail server and a new backup mx.
What I would like to know is what solution you guys would recommend for the mail server and the backup MX?
Any pointers would be greatly appreciated.
Regards, Coert
I use Mailscanner with postfix and Mailwatch to manage quarantine etc;
On the backup MX, I just use postfix and some basic anti-spam stuff. Very little gets through and even less gets through to the primary. I am aware that some spam techniques go straight to the backup MX because most people don't set it up quite as well as the primary. YMMV.
I also used to use greylisting, which does reduce spam, but, unfortunately it also reduces valid mail ;-) In the end I'd rather suffer a few spams getting through compared to the delayed receipt of important emails.
Brian.
On Mon, May 10, 2010 at 9:01 PM, Coert lgroups@waagmeester.co.za wrote:
Hello all,
About a year ago I set up a mail server on CentOS using this howto: http://wanderingbarque.com/howtos/mailserver/mailserver.html I managed to add amavisd-new with clamav and spamassassin. It runs very well, but it runs on CentOS 5.2, and if I try to upgrade, amavisd-new and clamav break. we are now also at the point where a backup mx will need to be implemented.
If necessary I am willing to implement a new mail server and a new backup mx.
What I would like to know is what solution you guys would recommend for the mail server and the backup MX?
Any pointers would be greatly appreciated.
Regards, Coert _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 5/10/2010 8:02 AM, Brian McKerr wrote:
I use Mailscanner with postfix and Mailwatch to manage quarantine etc;
On the backup MX, I just use postfix and some basic anti-spam stuff. Very little gets through and even less gets through to the primary. I am aware that some spam techniques go straight to the backup MX because most people don't set it up quite as well as the primary. YMMV.
I also used to use greylisting, which does reduce spam, but, unfortunately it also reduces valid mail ;-) In the end I'd rather suffer a few spams getting through compared to the delayed receipt of important emails.
Brian.
Another vote here for Mailscanner + Postfix. Add a few RBL's into your postfix config and spam will be at a minimum.
On 5/10/2010 8:19 AM, Ryan Manikowski wrote:
On 5/10/2010 8:02 AM, Brian McKerr wrote:
I use Mailscanner with postfix and Mailwatch to manage quarantine etc;
On the backup MX, I just use postfix and some basic anti-spam stuff. Very little gets through and even less gets through to the primary. I am aware that some spam techniques go straight to the backup MX because most people don't set it up quite as well as the primary. YMMV.
I also used to use greylisting, which does reduce spam, but, unfortunately it also reduces valid mail ;-) In the end I'd rather suffer a few spams getting through compared to the delayed receipt of important emails.
Another vote here for Mailscanner + Postfix. Add a few RBL's into your postfix config and spam will be at a minimum.
Or, if you like sendmail, MimeDefang works well to combine all the usual milter operations so you can control them with a simple perl snippet. Rpmforge has MimeDefang and Clamav packages that work together with a simple permission change so it is easy to stay up to date.
Am 10.05.2010 14:02, schrieb Brian McKerr:
I use Mailscanner with postfix and Mailwatch to manage quarantine etc;
I don't intend to start a flamewar, but given Wieste's repeated warnings on the Postfix mailinglist[1] and expressed on
http://www.postfix.org/addon.html
as
"mailscanner system, works with Postfix and other MTAs. WARNING: This software uses unsupported methods to manipulate Postfix queue files directly. This will result in corruption or loss of mail. The mailscanner authors have sofar refused to discuss a proper access API or protocol."
I call that combination not being best practice.
Regards
Alexander
[1] http://readlist.com/lists/postfix.org/postfix-users/7/36311.html
On Mon, 2010-05-10 at 20:33 +0200, Alexander Dalloz wrote:
Am 10.05.2010 14:02, schrieb Brian McKerr:
I use Mailscanner with postfix and Mailwatch to manage quarantine etc;
I don't intend to start a flamewar, but given Wieste's repeated warnings on the Postfix mailinglist[1] and expressed on
http://www.postfix.org/addon.html
as
"mailscanner system, works with Postfix and other MTAs. WARNING: This software uses unsupported methods to manipulate Postfix queue files directly. This will result in corruption or loss of mail. The mailscanner authors have sofar refused to discuss a proper access API or protocol."
I call that combination not being best practice.
---- clearly this is a personal issue that Wietse has with Julian (the author of MailScanner) and I can assure all that it works fine with Postfix and has never caused either corruption or loss of mail on many servers that I have configured to use both. There are also a lot of users who run MailScanner with Postfix.
Craig
On Tuesday, May 11, 2010 06:07 AM, Craig White wrote:
On Mon, 2010-05-10 at 20:33 +0200, Alexander Dalloz wrote:
Am 10.05.2010 14:02, schrieb Brian McKerr:
I use Mailscanner with postfix and Mailwatch to manage quarantine etc;
I don't intend to start a flamewar, but given Wieste's repeated warnings on the Postfix mailinglist[1] and expressed on
http://www.postfix.org/addon.html
as
"mailscanner system, works with Postfix and other MTAs. WARNING: This software uses unsupported methods to manipulate Postfix queue files directly. This will result in corruption or loss of mail. The mailscanner authors have sofar refused to discuss a proper access API or protocol."
I call that combination not being best practice.
clearly this is a personal issue that Wietse has with Julian (the author of MailScanner) and I can assure all that it works fine with Postfix and has never caused either corruption or loss of mail on many servers that I have configured to use both. There are also a lot of users who run MailScanner with Postfix.
I don't know about that. If it was sendmail, fine because sendmail does provide mechanisms for multiple access to a mail in the queue which is how sendmail itself treats mails in the queue when you have multiple queue runners. I have not used exim so as far as I know, only sendmail actually tolerates a third-party touching mails in the queue.
On Tue, 2010-05-11 at 09:40 +0800, Christopher Chan wrote:
On Tuesday, May 11, 2010 06:07 AM, Craig White wrote:
On Mon, 2010-05-10 at 20:33 +0200, Alexander Dalloz wrote:
Am 10.05.2010 14:02, schrieb Brian McKerr:
I use Mailscanner with postfix and Mailwatch to manage quarantine etc;
I don't intend to start a flamewar, but given Wieste's repeated warnings on the Postfix mailinglist[1] and expressed on
http://www.postfix.org/addon.html
as
"mailscanner system, works with Postfix and other MTAs. WARNING: This software uses unsupported methods to manipulate Postfix queue files directly. This will result in corruption or loss of mail. The mailscanner authors have sofar refused to discuss a proper access API or protocol."
I call that combination not being best practice.
clearly this is a personal issue that Wietse has with Julian (the author of MailScanner) and I can assure all that it works fine with Postfix and has never caused either corruption or loss of mail on many servers that I have configured to use both. There are also a lot of users who run MailScanner with Postfix.
I don't know about that. If it was sendmail, fine because sendmail does provide mechanisms for multiple access to a mail in the queue which is how sendmail itself treats mails in the queue when you have multiple queue runners. I have not used exim so as far as I know, only sendmail actually tolerates a third-party touching mails in the queue.
---- clearly this isn't rocket science and the manipulation of the mail queue is rather straight forward and hardly worth all of the rancor that Wietse seems to direct towards Julian/MailScanner.
I started with Sendmail and MailScanner was written with Sendmail in mind and adapted later for Exim & Postfix. When I was trying to switch to Postfix, I couldn't stand amavisd and went back to MailScanner and decided to just ignore the warnings from Wietse and I discovered that many on the MailScanner list came to the same conclusion.
With reference to your other message in this thread, MailScanner calls spamd/clamd as part of the process but the real value in my mind is the granular handling in MailScanner which is sort of complete overkill but it totally works and scratches about every itch you ever had in running a mail server.
Craig
On Tuesday, May 11, 2010 11:02 AM, Craig White wrote:
On Tue, 2010-05-11 at 09:40 +0800, Christopher Chan wrote:
On Tuesday, May 11, 2010 06:07 AM, Craig White wrote:
On Mon, 2010-05-10 at 20:33 +0200, Alexander Dalloz wrote:
Am 10.05.2010 14:02, schrieb Brian McKerr:
I use Mailscanner with postfix and Mailwatch to manage quarantine etc;
I don't intend to start a flamewar, but given Wieste's repeated warnings on the Postfix mailinglist[1] and expressed on
http://www.postfix.org/addon.html
as
"mailscanner system, works with Postfix and other MTAs. WARNING: This software uses unsupported methods to manipulate Postfix queue files directly. This will result in corruption or loss of mail. The mailscanner authors have sofar refused to discuss a proper access API or protocol."
I call that combination not being best practice.
clearly this is a personal issue that Wietse has with Julian (the author of MailScanner) and I can assure all that it works fine with Postfix and has never caused either corruption or loss of mail on many servers that I have configured to use both. There are also a lot of users who run MailScanner with Postfix.
I don't know about that. If it was sendmail, fine because sendmail does provide mechanisms for multiple access to a mail in the queue which is how sendmail itself treats mails in the queue when you have multiple queue runners. I have not used exim so as far as I know, only sendmail actually tolerates a third-party touching mails in the queue.
clearly this isn't rocket science and the manipulation of the mail queue is rather straight forward and hardly worth all of the rancor that Wietse seems to direct towards Julian/MailScanner.
sendmail checks for locks on queue files and so multiple sendmail processes + third party processes can operate on a sendmail queue at the time.
There is no such provision on qmail or postfix. Queue manipulation on postfix should be done through postsuper instead of directly mucking about with the queue file in whatever postfix subqueue while postfix is live.
I started with Sendmail and MailScanner was written with Sendmail in mind and adapted later for Exim& Postfix. When I was trying to switch to Postfix, I couldn't stand amavisd and went back to MailScanner and decided to just ignore the warnings from Wietse and I discovered that many on the MailScanner list came to the same conclusion.
Never used mailscanner but I am sure that is very little out there that can knock amavis of the top of the hill of top cpu chewers.
With reference to your other message in this thread, MailScanner calls spamd/clamd as part of the process but the real value in my mind is the granular handling in MailScanner which is sort of complete overkill but it totally works and scratches about every itch you ever had in running a mail server.
I'm sure the same can be said of mimedefang and more. When I find something is not met by the postfix provided mechanisms, I'll take a look at these other solutions.
Christopher Chan wrote:
With reference to your other message in this thread, MailScanner calls spamd/clamd as part of the process but the real value in my mind is the granular handling in MailScanner which is sort of complete overkill but it totally works and scratches about every itch you ever had in running a mail server.
I'm sure the same can be said of mimedefang and more. When I find something is not met by the postfix provided mechanisms, I'll take a look at these other solutions.
MimeDefang is about as efficient as you can get because it multiplexes the milter hooks separately as needed between the front/back end processes so it doesn't keep a perl process running for every sendmail process and you don't have fast operations waiting for slow ones to complete - and it runs spamassassin in the backend daemon processes instead of starting a new copy for each message. Plus, it splits out the attachments only once for as many scanning operations as you configure.
In theory, you can run MimeDefang as a postfix milter these days but I don't know if it actually works.
On Tuesday, May 11, 2010 01:46 PM, Les Mikesell wrote:
Christopher Chan wrote:
With reference to your other message in this thread, MailScanner calls spamd/clamd as part of the process but the real value in my mind is the granular handling in MailScanner which is sort of complete overkill but it totally works and scratches about every itch you ever had in running a mail server.
I'm sure the same can be said of mimedefang and more. When I find something is not met by the postfix provided mechanisms, I'll take a look at these other solutions.
MimeDefang is about as efficient as you can get because it multiplexes the milter hooks separately as needed between the front/back end processes so it doesn't keep a perl process running for every sendmail process and you don't have fast operations waiting for slow ones to complete - and it runs spamassassin in the backend daemon processes instead of starting a new copy for each message. Plus, it splits out the attachments only once for as many scanning operations as you configure.
In theory, you can run MimeDefang as a postfix milter these days but I don't know if it actually works.
It should. postfix's support of milter should have reached the level that mimedefang uses a year or two iirc. It should support changing the recipient and what not. that I don't quite recall right now. that mimedefang expects from the milter interface.
Coert wrote:
Hello all,
About a year ago I set up a mail server on CentOS using this howto: http://wanderingbarque.com/howtos/mailserver/mailserver.html I managed to add amavisd-new with clamav and spamassassin. It runs very well, but it runs on CentOS 5.2, and if I try to upgrade, amavisd-new and clamav break. we are now also at the point where a backup mx will need to be implemented.
If necessary I am willing to implement a new mail server and a new backup mx.
What I would like to know is what solution you guys would recommend for the mail server and the backup MX?
Any pointers would be greatly appreciated.
Regards, Coert
I would follow the CentOS Wiki HowTo docs for Postfix, which are currently maintained for CentOS 5:
http://wiki.centos.org/HowTos#head-0facb50d5796bee0bd394636c32ffa9a997a6ab5
http://wiki.centos.org/HowTos/postfix http://wiki.centos.org/HowTos/Amavisd
If things break, report it and I'll fix the documentation. I'm running that setup so I do tend to notice when things break.
I've recently updated to the latest amavisd-new, clamav and spamassassin - all largely without issue but I would always advise you read the release notes and track their respective mailing lists for potential issues.
Rob Kampen wrote:
Ned Slider wrote:
Coert wrote:
Hello all,
About a year ago I set up a mail server on CentOS using this howto: http://wanderingbarque.com/howtos/mailserver/mailserver.html I managed to add amavisd-new with clamav and spamassassin. It runs very well, but it runs on CentOS 5.2, and if I try to upgrade, amavisd-new and clamav break. we are now also at the point where a backup mx will need to be implemented.
If necessary I am willing to implement a new mail server and a new backup mx.
What I would like to know is what solution you guys would recommend for the mail server and the backup MX?
Any pointers would be greatly appreciated.
Regards, Coert
I would follow the CentOS Wiki HowTo docs for Postfix, which are currently maintained for CentOS 5:
http://wiki.centos.org/HowTos#head-0facb50d5796bee0bd394636c32ffa9a997a6ab5
http://wiki.centos.org/HowTos/postfix http://wiki.centos.org/HowTos/Amavisd
If things break, report it and I'll fix the documentation. I'm running that setup so I do tend to notice when things break.
I've recently updated to the latest amavisd-new, clamav and spamassassin
- all largely without issue but I would always advise you read the
release notes and track their respective mailing lists for potential issues.
+1 - I use this setup on a number servers / domains - it just seems to work - thanks for keeping this current.
Ah, don't thank me, I just wrote the docs - the real thanks is due to the guys upstream who write the software and the packagers at rpmforge who make sure it integrates well into the distro :)
Ned Slider wrote:
Coert wrote:
Hello all,
About a year ago I set up a mail server on CentOS using this howto: http://wanderingbarque.com/howtos/mailserver/mailserver.html I managed to add amavisd-new with clamav and spamassassin. It runs very well, but it runs on CentOS 5.2, and if I try to upgrade, amavisd-new and clamav break. we are now also at the point where a backup mx will need to be implemented.
If necessary I am willing to implement a new mail server and a new backup mx.
What I would like to know is what solution you guys would recommend for the mail server and the backup MX?
Any pointers would be greatly appreciated.
Regards, Coert
I would follow the CentOS Wiki HowTo docs for Postfix, which are currently maintained for CentOS 5:
http://wiki.centos.org/HowTos#head-0facb50d5796bee0bd394636c32ffa9a997a6ab5
http://wiki.centos.org/HowTos/postfix http://wiki.centos.org/HowTos/Amavisd
If things break, report it and I'll fix the documentation. I'm running that setup so I do tend to notice when things break.
I've recently updated to the latest amavisd-new, clamav and spamassassin
- all largely without issue but I would always advise you read the
release notes and track their respective mailing lists for potential issues.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Hello Ned,
Thank you for the links, and all the work you put in!
I also obtained Oreilly's Definitive Guide to Postfix, for some extra reading, also because I will need virtual domains..
Kind regards, Coert
Am 10.05.10 13:01, schrieb Coert:
Hello all,
About a year ago I set up a mail server on CentOS using this howto: http://wanderingbarque.com/howtos/mailserver/mailserver.html I managed to add amavisd-new with clamav and spamassassin. It runs very well, but it runs on CentOS 5.2, and if I try to upgrade, amavisd-new and clamav break.
Oh please don't say what happens. If you use amavisd-new and clamav from rpmforge (or from epel), they don't break when updating. And please don't tell me you ran clamav non-updated since CentOS 5.2 - it had several security issues since then.
Ralph
On 05/10/2010 11:37 AM, Ralph Angenendt wrote:
Am 10.05.10 13:01, schrieb Coert:
Hello all,
About a year ago I set up a mail server on CentOS using this howto: http://wanderingbarque.com/howtos/mailserver/mailserver.html I managed to add amavisd-new with clamav and spamassassin. It runs very well, but it runs on CentOS 5.2, and if I try to upgrade, amavisd-new and clamav break.
Oh please don't say what happens. If you use amavisd-new and clamav from rpmforge (or from epel), they don't break when updating. And please don't tell me you ran clamav non-updated since CentOS 5.2 - it had several security issues since then.
Actually, they do (break when updating, that is).
The problem is at least one of the packagers for clamd/amavisd-new blindly overrides the path to clamd.sock by overwriting the config file leaving the two out-of-sync (and so unable to function).
It is easily fixed by resetting the path - but you do have to watch out for it on upgrades.
On 5/10/2010 2:51 PM, Benjamin Franz wrote:
On 05/10/2010 11:37 AM, Ralph Angenendt wrote:
Am 10.05.10 13:01, schrieb Coert:
Hello all,
About a year ago I set up a mail server on CentOS using this howto: http://wanderingbarque.com/howtos/mailserver/mailserver.html I managed to add amavisd-new with clamav and spamassassin. It runs very well, but it runs on CentOS 5.2, and if I try to upgrade, amavisd-new and clamav break.
Oh please don't say what happens. If you use amavisd-new and clamav from rpmforge (or from epel), they don't break when updating. And please don't tell me you ran clamav non-updated since CentOS 5.2 - it had several security issues since then.
Actually, they do (break when updating, that is).
The problem is at least one of the packagers for clamd/amavisd-new blindly overrides the path to clamd.sock by overwriting the config file leaving the two out-of-sync (and so unable to function).
It is easily fixed by resetting the path - but you do have to watch out for it on upgrades.
Is this a result of having multiple uncoordinated 3rd party repositories enabled during an update and flipping repositories as the version numbering jumps (more or less expected behavior...) or are you saying that a single packager flipped the format in an incompatible way?
On 05/10/2010 01:30 PM, Les Mikesell wrote:
On 5/10/2010 2:51 PM, Benjamin Franz wrote:
Actually, they do (break when updating, that is).
The problem is at least one of the packagers for clamd/amavisd-new blindly overrides the path to clamd.sock by overwriting the config file leaving the two out-of-sync (and so unable to function).
It is easily fixed by resetting the path - but you do have to watch out for it on upgrades.
Is this a result of having multiple uncoordinated 3rd party repositories enabled during an update and flipping repositories as the version numbering jumps (more or less expected behavior...) or are you saying that a single packager flipped the format in an incompatible way?
This is using rpmforge/Dag (only). That is the only 3rd party repo I use for my production systems. Updates of clamd has replaced /etc/clamd.conf twice on me in the last year or two, each time breaking my mail system until I fixed it. Most recently in April of this year.
Benjamin Franz wrote:
On 05/10/2010 01:30 PM, Les Mikesell wrote:
On 5/10/2010 2:51 PM, Benjamin Franz wrote:
Actually, they do (break when updating, that is).
The problem is at least one of the packagers for clamd/amavisd-new blindly overrides the path to clamd.sock by overwriting the config file leaving the two out-of-sync (and so unable to function).
It is easily fixed by resetting the path - but you do have to watch out for it on upgrades.
Is this a result of having multiple uncoordinated 3rd party repositories enabled during an update and flipping repositories as the version numbering jumps (more or less expected behavior...) or are you saying that a single packager flipped the format in an incompatible way?
This is using rpmforge/Dag (only). That is the only 3rd party repo I use for my production systems. Updates of clamd has replaced /etc/clamd.conf twice on me in the last year or two, each time breaking my mail system until I fixed it. Most recently in April of this year.
Should I be worried if the only clamd.conf on the mail server is in /usr/share/doc?
Virus scanning is working.
Coert wrote:
Benjamin Franz wrote:
On 05/10/2010 01:30 PM, Les Mikesell wrote:
On 5/10/2010 2:51 PM, Benjamin Franz wrote:
Actually, they do (break when updating, that is).
The problem is at least one of the packagers for clamd/amavisd-new blindly overrides the path to clamd.sock by overwriting the config file leaving the two out-of-sync (and so unable to function).
It is easily fixed by resetting the path - but you do have to watch out for it on upgrades.
Is this a result of having multiple uncoordinated 3rd party repositories enabled during an update and flipping repositories as the version numbering jumps (more or less expected behavior...) or are you saying that a single packager flipped the format in an incompatible way?
This is using rpmforge/Dag (only). That is the only 3rd party repo I use for my production systems. Updates of clamd has replaced /etc/clamd.conf twice on me in the last year or two, each time breaking my mail system until I fixed it. Most recently in April of this year.
Should I be worried if the only clamd.conf on the mail server is in /usr/share/doc?
Virus scanning is working. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Sorry about that, false alarm. It runs via amavis currently and its config is in /etc/clamd.d/amavisd.conf
Been using sendmail-clamav-mimedefang-greylist combo for years and have never had a problem.
Standard package: sendmail-devel-8.13.8-2.el5 sendmail-cf-8.13.8-2.el5 sendmail-doc-8.13.8-2.el5 sendmail-8.13.8-2.el5
From rpmforge:
mimedefang.2.68-1.el5 clamd-0.96-2.el5 clamav-0.96-2.el5 clamav-milter-0.96-2.el5 milter-greylist.3.0-2.el5
The important settings to get this to work:
sendmail.mc: INPUT_MAIL_FILTER(`greylist', `S=local:/var/milter-greylist/milter-greylist.sock, F=T, T=S:3m;R:3m') INPUT_MAIL_FILTER(`mimedefang', `S=unix:/var/spool/MIMEDefang/mimedefang.sock, F=T, T=S:3m;R:3m') INPUT_MAIL_FILTER(`clamav',`S=local:/var/clamav/clamav_milter.sock, F=T, T=S:4m;R:4m')dnl
clamav-milter.conf: MilterSocket unix:/var/clamav/clamav_milter.sock
clamd.conf: LocalSocket /var/clamav/clamd_local.sock
/etc/rc.d/init.d/mimedefang: SPOOLDIR='/var/spool/MIMEDefang' SOCKET=${SOCKET:=$SPOOLDIR/$prog.sock}
/etc/mail/greylist.conf: socket "/var/milter-greylist/milter-greylist.sock"
As for the secondary MX (on a different host) running the same OS just copy ALL the config, its that easy. However, on the PRIMARY host you need to make sure that the SECONDARY MX has access to hand over mail.
Jobst
On Mon, May 10, 2010 at 01:01:13PM +0200, Coert (lgroups@waagmeester.co.za) wrote:
Hello all,
About a year ago I set up a mail server on CentOS using this howto: http://wanderingbarque.com/howtos/mailserver/mailserver.html I managed to add amavisd-new with clamav and spamassassin. It runs very well, but it runs on CentOS 5.2, and if I try to upgrade, amavisd-new and clamav break. we are now also at the point where a backup mx will need to be implemented.
If necessary I am willing to implement a new mail server and a new backup mx.
What I would like to know is what solution you guys would recommend for the mail server and the backup MX?
Any pointers would be greatly appreciated.
Regards, Coert _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-----Original Message----- If necessary I am willing to implement a new mail server and a new backup mx.
What I would like to know is what solution you guys would recommend for the mail server and the backup MX?
Any pointers would be greatly appreciated.
Running a backup or secondary MX at this point is largely a waste of time. The only thing a backup MX gets you is an increase in spam.
Most MTAs will retry sending every couple of hours. So if your MX is down for a while, it's not really a big issue.
I run a cluster of sendmail servers (at MX 0) with spamassassin and clamav, and it works quite well. Provides redundnacy and scalability, without the nonsense of a backup mx.
The last "backup" MX I ran was probably retired at least two years ago, and even then it was well past pointless and irrelevant.
Cheers,
Dan
On Monday, May 10, 2010 07:01 PM, Coert wrote:
Hello all,
About a year ago I set up a mail server on CentOS using this howto: http://wanderingbarque.com/howtos/mailserver/mailserver.html I managed to add amavisd-new with clamav and spamassassin. It runs very well, but it runs on CentOS 5.2, and if I try to upgrade, amavisd-new and clamav break. we are now also at the point where a backup mx will need to be implemented.
I run postfix with clamd and spamd 'plugged in' via milter. Amavis is a dog. Mind you, I repackage more recent versions of postfix and I have to likewise do the milters for clamav and spamassassin.
If necessary I am willing to implement a new mail server and a new backup mx.
What I would like to know is what solution you guys would recommend for the mail server and the backup MX?
'Backup mx' should always have access at least to the same user address table that the primary uses. Or just run two identical mx's with the same priority.
-
Alexander Dalloz -
Benjamin Franz -
Brian McKerr -
Christopher Chan -
Coert -
Craig White -
Dan Irwin -
Jobst Schmalenbach -
Les Mikesell -
Ned Slider -
Ralph Angenendt -
Rob Kampen -
Ryan Manikowski