I have had the same email address since 1997 (when microsoft stole bob.com from me thanks to network solutions...)
In the early days I of course was free with my email and used it everwhere. Fast forward to 2012, some 15 years later.
woof..the amount of spam sent to me has always just kept getting worse and worse.
On my centos 5 server I just used sendmail with spamassassin and it killed a lot. Still, 100s, sometimes more made it through. Then thunderbird would weed out more, learned as it went... Still, had an inbox with a lot of junk.
Now I have set up a centos 6 box using postfix. Today I decided to try to add smtpd restrictions. After a lot of reading and testing I 'seem' to be doing incredible. I wanted to share my current working postfix smtpd restrictions area so that others who are interested can start with it.
I just added the helo and sender restrictions and have noticed no problems yet. There were many things some sites said to add, but they killed some very legitimate mail.
So...yesterday a few hundred mails in my box as usual. Plus I set up procmail to not delete spam so I could test. That gave me hundreds more....
30 minutes since putting this up I went from 1 every few seconds to 1 in 30 minutes. And that was tagged by spamassassin as spam. 1.
Not sure if this setup is perfect, but it is working quite well. Yes, the mail takes a few seconds longer and there is probably more I could do, but this ROCKS!!!
smtpd_delay_reject = yes smtpd_helo_required = yes
smtpd_client_restrictions = permit_mynetworks,permit
smtpd_helo_restrictions = permit_mynetworks, reject_non_fqdn_helo_hostname, reject_invalid_helo_hostname, permit
smtpd_sender_restrictions = permit_mynetworks, reject_non_fqdn_sender, reject_unknown_sender_domain, permit
smtpd_recipient_restrictions = reject_non_fqdn_recipient, reject_unknown_recipient_domain, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, reject_invalid_hostname, reject_unauth_pipelining, reject_rbl_client zen.spamhaus.org, reject_rbl_client truncate.gbudb.net, reject_rbl_client dnsbl.njabl.org reject_rbl_client cbl.abuseat.org reject_rbl_client bl.spamcop.net, reject_rbl_client dnsbl.sorbs.net, sleep 1, permit
smtpd_data_restrictions = permit_mynetworks, reject_multi_recipient_bounce, permit
Bob Hoffman wrote:
I have had the same email address since 1997 (when microsoft stole bob.com from me thanks to network solutions...)
I remember reading about you, vaguely. <snip>
Now I have set up a centos 6 box using postfix. Today I decided to try to add smtpd restrictions. After a lot of reading and testing I 'seem' to be doing incredible. I wanted to share my current working postfix smtpd restrictions area so that others who are interested can start with it.
<snip> Here's a question: is there any way to inspect an email's headers, and reject it if the alleged FWDN in the From:" doesn't match the oldest "Received: "?
mark
On 03/12/2012 02:25 PM, m.roth@5-cent.us wrote:
Bob Hoffman wrote:
I have had the same email address since 1997 (when microsoft stole bob.com from me thanks to network solutions...)
I remember reading about you, vaguely.
<snip> > Now I have set up a centos 6 box using postfix. Today I decided to try > to add smtpd restrictions. After a lot of reading and testing I 'seem' > to be doing incredible. > I wanted to share my current working postfix smtpd restrictions area so > that others who are interested can start with it. <snip> Here's a question: is there any way to inspect an email's headers, and reject it if the alleged FWDN in the From:" doesn't match the oldest "Received: "?
mark
That would be a good test. Postfix does have the ability to match regular expressions on headers, but the tests are limited to testing a single line at a time. You can however write one of several types of postfix content inspection modules using your favorite programming or scripting language. If you use one of the before queue inspection methods and you have a busy mail server, you have to watch out that you don't introduce delays that could cause clients to time out.
You might also look around to see if there's something out there that would already do that.
Check out http://www.postfix.org/CONTENT_INSPECTION_README.html I don't think it's that hard to throw together a perl or python script to do this. I have more experience with the policy daemon though.
Nataraj
On Mon, Mar 12, 2012 at 9:48 PM, Nataraj incoming-centos@rjl.com wrote:
On 03/12/2012 02:25 PM, m.roth@5-cent.us wrote:
Bob Hoffman wrote:
I have had the same email address since 1997 (when microsoft stole bob.com from me thanks to network solutions...)
I remember reading about you, vaguely.
<snip> > Now I have set up a centos 6 box using postfix. Today I decided to try > to add smtpd restrictions. After a lot of reading and testing I 'seem' > to be doing incredible. > I wanted to share my current working postfix smtpd restrictions area so > that others who are interested can start with it. <snip> Here's a question: is there any way to inspect an email's headers, and reject it if the alleged FWDN in the From:" doesn't match the oldest "Received: "?
mark
That would be a good test. Postfix does have the ability to match regular expressions on headers, but the tests are limited to testing a single line at a time. You can however write one of several types of postfix content inspection modules using your favorite programming or scripting language. If you use one of the before queue inspection methods and you have a busy mail server, you have to watch out that you don't introduce delays that could cause clients to time out.
You might also look around to see if there's something out there that would already do that.
Check out http://www.postfix.org/CONTENT_INSPECTION_README.html I don't think it's that hard to throw together a perl or python script to do this. I have more experience with the policy daemon though.
With sendmail, using MimeDefang as a milter was one of the best approaches, because then you could control all of the other usual (spamassassin, clamav, etc.) or custom steps with a small snippet of perl. I think the postfix milter interface is at least theoretically compatible these days but I haven't tried them together. The way MimeDefang multiplexes the fast/slow operations and extracts the attachments only once for any number of scans is particularly efficient.
On Mon, Mar 12, 2012 at 07:48:14PM -0700, Nataraj wrote:
On 03/12/2012 02:25 PM, m.roth@5-cent.us wrote:
Here's a question: is there any way to inspect an email's headers, and reject it if the alleged FWDN in the From:" doesn't match the oldest "Received: "?
That would be a good test. Postfix does have the ability to match
It would be a _terrible_ test and would fail legitimate mail. e.g. all those people with their domains delegated to google; the source address might be their home internet IP and none of the rest of the machines would contain the FQDN. Heck, even people who use their ISPs mail relay could suffer this one! Some anti-virus software inserts Received headers. Large corporations with multiple DNS domains. Or people with home networks and their smart host that then forwards to an authorised relay. ...
And that's just off the top of my head.
I believe you'd get a fair false-positive with such a test.
On Mar 12, 2012, at 5:25 PM, m.roth@5-cent.us wrote:
Here's a question: is there any way to inspect an email's headers, and reject it if the alleged FWDN in the From:" doesn't match the oldest "Received: "?
That would be problematic with dual homed mail gateways that received on internal interface and delivered on external interface that had different host names on each.
-Ross
Ross Walker wrote:
On Mar 12, 2012, at 5:25 PM, m.roth@5-cent.us wrote:
Here's a question: is there any way to inspect an email's headers, and reject it if the alleged FWDN in the From:" doesn't match the oldest "Received: "?
That would be problematic with dual homed mail gateways that received on internal interface and delivered on external interface that had different host names on each.
I'm just trying to think of ways around a blacklist... *esp* the way dnsorb does, where they'll blacklist an entire block that belongs to a hosting provider, who provides one external delivery address.
mark "why, yes, that has happened to me several times"
On 03/13/2012 07:02 AM, m.roth@5-cent.us wrote:
Ross Walker wrote:
On Mar 12, 2012, at 5:25 PM, m.roth@5-cent.us wrote:
Here's a question: is there any way to inspect an email's headers, and reject it if the alleged FWDN in the From:" doesn't match the oldest "Received: "?
That would be problematic with dual homed mail gateways that received on internal interface and delivered on external interface that had different host names on each.
I'm just trying to think of ways around a blacklist... *esp* the way dnsorb does, where they'll blacklist an entire block that belongs to a hosting provider, who provides one external delivery address.
mark "why, yes, that has happened to me several times"
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Ok, so it wouldn't work to just use the oldest received, but a smarter inspection could check to see weather it actually passed through a server owned by the claimed domain. The reality is that what is need is to input this into a scoring system weighted with other spam evaluation mechanisms, something like spamassassin. The downside of spamassasin is that it is costly to run and must be run after the message is accepted by the smtp server.
There already exist so many different spam control methods, many of them can run at the smtp level and reject mail prior to accepting. I get pretty decent rejection from greylisting. Postscreen is supposed to be quite good for detecting any kind of bot attacks. I'm currently using other techniques for bot attacks, but plan on switching to postscreen.
I also run fail2ban and block IP addresses when I get repeated smtp errors from an IP, this substantially reduces any kind of bulk spam attack which attempts to guess valid mail recipients.
I would look at the milter that Les mentioned. I haven't had a a chance yet.
Nataraj
On Tue, Mar 13, 2012 at 12:00 PM, Nataraj incoming-centos@rjl.com wrote:
Ok, so it wouldn't work to just use the oldest received, but a smarter inspection could check to see weather it actually passed through a server owned by the claimed domain. The reality is that what is need is to input this into a scoring system weighted with other spam evaluation mechanisms, something like spamassassin. The downside of spamassasin is that it is costly to run and must be run after the message is accepted by the smtp server.
MimeDefang runs it as part of its own milter process so you don't start a new perl for each message (and multiplexed so there is not necessarily an instance for every mailer process), and at a point where you can do an smtp reject based on the content.
There already exist so many different spam control methods, many of them can run at the smtp level and reject mail prior to accepting. I get pretty decent rejection from greylisting.
MimeDefang doesn't do greylisting although the hooks are there if you wanted to do it yourself. But, you can run multiple milters and milter-greylist works OK.
I would look at the milter that Les mentioned. I haven't had a a chance yet.
I set up the package from rpmforge a long time ago along with their clamav. I see they are both in epel now - not sure what you would have to do to make them work with postfix, though. I've seen them mentioned together on the mimedefang mail list, so someone must be doing it.
On 03/13/2012 11:05 AM, Les Mikesell wrote:
On Tue, Mar 13, 2012 at 12:00 PM, Nataraj incoming-centos@rjl.com wrote:
Ok, so it wouldn't work to just use the oldest received, but a smarter inspection could check to see weather it actually passed through a server owned by the claimed domain. The reality is that what is need is to input this into a scoring system weighted with other spam evaluation mechanisms, something like spamassassin. The downside of spamassasin is that it is costly to run and must be run after the message is accepted by the smtp server.
MimeDefang runs it as part of its own milter process so you don't start a new perl for each message (and multiplexed so there is not necessarily an instance for every mailer process), and at a point where you can do an smtp reject based on the content.
There already exist so many different spam control methods, many of them can run at the smtp level and reject mail prior to accepting. I get pretty decent rejection from greylisting.
MimeDefang doesn't do greylisting although the hooks are there if you wanted to do it yourself. But, you can run multiple milters and milter-greylist works OK.
I would look at the milter that Les mentioned. I haven't had a a chance yet.
I set up the package from rpmforge a long time ago along with their clamav. I see they are both in epel now - not sure what you would have to do to make them work with postfix, though. I've seen them mentioned together on the mimedefang mail list, so someone must be doing it.
I run clamav and the greylisting implementation and the spamassasin interface that's included with vpostmaster. It's not perfect, but it's all quite nicely coded in python and easy to tweak. The GUI allows changing spamassasin, greylisting, clamav parameters on a per user basis. Users can also login to the gui and manage their own spam control. The database also has designed in, the ability to store per user configuration for other modules that you might add yourself. I will look at MimeDefang.
Nataraj
Nataraj
I need something for a very small shop and have been looking...been reading the comments. Is vpostmaster easy to setup and maintain, I'm looking for something lightweight and works for spam, I support them after hours and looking for something that just works....
On Tue, Mar 13, 2012 at 1:22 PM, Nataraj incoming-centos@rjl.com wrote:
On 03/13/2012 11:05 AM, Les Mikesell wrote:
On Tue, Mar 13, 2012 at 12:00 PM, Nataraj incoming-centos@rjl.com
wrote:
Ok, so it wouldn't work to just use the oldest received, but a smarter inspection could check to see weather it actually passed through a server owned by the claimed domain. The reality is that what is need is to input this into a scoring system weighted with other spam evaluation mechanisms, something like spamassassin. The downside of spamassasin is that it is costly to run and must be run after the message is accepted by the smtp server.
MimeDefang runs it as part of its own milter process so you don't start a new perl for each message (and multiplexed so there is not necessarily an instance for every mailer process), and at a point where you can do an smtp reject based on the content.
There already exist so many different spam control methods, many of them can run at the smtp level and reject mail prior to accepting. I get pretty decent rejection from greylisting.
MimeDefang doesn't do greylisting although the hooks are there if you wanted to do it yourself. But, you can run multiple milters and milter-greylist works OK.
I would look at the milter that Les mentioned. I haven't had a a chance yet.
I set up the package from rpmforge a long time ago along with their clamav. I see they are both in epel now - not sure what you would have to do to make them work with postfix, though. I've seen them mentioned together on the mimedefang mail list, so someone must be doing it.
I run clamav and the greylisting implementation and the spamassasin interface that's included with vpostmaster. It's not perfect, but it's all quite nicely coded in python and easy to tweak. The GUI allows changing spamassasin, greylisting, clamav parameters on a per user basis. Users can also login to the gui and manage their own spam control. The database also has designed in, the ability to store per user configuration for other modules that you might add yourself. I will look at MimeDefang.
Nataraj
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 03/13/2012 11:28 AM, Tom Bishop wrote:
Nataraj
I need something for a very small shop and have been looking...been reading the comments. Is vpostmaster easy to setup and maintain, I'm looking for something lightweight and works for spam, I support them after hours and looking for something that just works....
Vpostmaster is very easy to setup, provided you start with a clean linux install (CentOS is good choice). Don't install it on a system where you've already installed postfix, dovecot etc. For a small site it runs very well in a VM. A VM is certainly adequate for testing.
I have done some customization to my config, but I don't really think that's necessary for most small sites. It's certainly better then piecing together all the components yourself. The install package will provide you with a working postfix, dovecot, greylisting, clamav, spamassassin, spf etc and you can always add any additional postfix compatibile addons. The commercial version is still open source and gets a few extra features over the free version. I currently run the free version, but I like the author and plan to spring for the commercial version.
http://www.tummy.com/Products/vpostmaster
There are a 2 or 3 alternatives that provide an integrated mail system based on postfix. I looked at them a while back and all were less attractive to me. I'd have to dig up their names, but one is a package in the fedora repositories. I think it's written in java. Sounded like a nightmare to me.
Nataraj
One more thing, I did a quick search and it appears that they are now supporting 6.x code...have you given that a try yet...I already have a centos 6.2 vmware template that would make it quick and easy to spool up...
On Tue, Mar 13, 2012 at 1:56 PM, Nataraj incoming-centos@rjl.com wrote:
On 03/13/2012 11:28 AM, Tom Bishop wrote:
Nataraj
I need something for a very small shop and have been looking...been reading the comments. Is vpostmaster easy to setup and maintain, I'm looking for something lightweight and works for spam, I support them
after
hours and looking for something that just works....
Vpostmaster is very easy to setup, provided you start with a clean linux install (CentOS is good choice). Don't install it on a system where you've already installed postfix, dovecot etc. For a small site it runs very well in a VM. A VM is certainly adequate for testing.
I have done some customization to my config, but I don't really think that's necessary for most small sites. It's certainly better then piecing together all the components yourself. The install package will provide you with a working postfix, dovecot, greylisting, clamav, spamassassin, spf etc and you can always add any additional postfix compatibile addons. The commercial version is still open source and gets a few extra features over the free version. I currently run the free version, but I like the author and plan to spring for the commercial version.
http://www.tummy.com/Products/vpostmaster
There are a 2 or 3 alternatives that provide an integrated mail system based on postfix. I looked at them a while back and all were less attractive to me. I'd have to dig up their names, but one is a package in the fedora repositories. I think it's written in java. Sounded like a nightmare to me.
Nataraj
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 03/13/2012 12:03 PM, Tom Bishop wrote:
One more thing, I did a quick search and it appears that they are now supporting 6.x code...have you given that a try yet...I already have a centos 6.2 vmware template that would make it quick and easy to spool up...
I'm still running on CentOS 5, but I'm on the mailing list and I'm pretty sure that CentOS 6 works now. One thing that I do recommend is that if your not real familiar with postfix and your going to do your own tweaking, keep a test VM around. I also install updates first on my test system before updating my production server.
Nataraj
On Tue, Mar 13, 2012 at 1:56 PM, Nataraj incoming-centos@rjl.com wrote:
On 03/13/2012 11:28 AM, Tom Bishop wrote:
Nataraj
I need something for a very small shop and have been looking...been reading the comments. Is vpostmaster easy to setup and maintain, I'm looking for something lightweight and works for spam, I support them
after
hours and looking for something that just works....
Vpostmaster is very easy to setup, provided you start with a clean linux install (CentOS is good choice). Don't install it on a system where you've already installed postfix, dovecot etc. For a small site it runs very well in a VM. A VM is certainly adequate for testing.
I have done some customization to my config, but I don't really think that's necessary for most small sites. It's certainly better then piecing together all the components yourself. The install package will provide you with a working postfix, dovecot, greylisting, clamav, spamassassin, spf etc and you can always add any additional postfix compatibile addons. The commercial version is still open source and gets a few extra features over the free version. I currently run the free version, but I like the author and plan to spring for the commercial version.
http://www.tummy.com/Products/vpostmaster
There are a 2 or 3 alternatives that provide an integrated mail system based on postfix. I looked at them a while back and all were less attractive to me. I'd have to dig up their names, but one is a package in the fedora repositories. I think it's written in java. Sounded like a nightmare to me.
Nataraj
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Good point, will add it to my long list of things to get done :)
On Tue, Mar 13, 2012 at 2:09 PM, Nataraj incoming-centos@rjl.com wrote:
On 03/13/2012 12:03 PM, Tom Bishop wrote:
One more thing, I did a quick search and it appears that they are now supporting 6.x code...have you given that a try yet...I already have a centos 6.2 vmware template that would make it quick and easy to spool
up...
I'm still running on CentOS 5, but I'm on the mailing list and I'm pretty sure that CentOS 6 works now. One thing that I do recommend is that if your not real familiar with postfix and your going to do your own tweaking, keep a test VM around. I also install updates first on my test system before updating my production server.
Nataraj
On Tue, Mar 13, 2012 at 1:56 PM, Nataraj incoming-centos@rjl.com
wrote:
On 03/13/2012 11:28 AM, Tom Bishop wrote:
Nataraj
I need something for a very small shop and have been looking...been reading the comments. Is vpostmaster easy to setup and maintain, I'm looking for something lightweight and works for spam, I support them
after
hours and looking for something that just works....
Vpostmaster is very easy to setup, provided you start with a clean linux install (CentOS is good choice). Don't install it on a system where you've already installed postfix, dovecot etc. For a small site it runs very well in a VM. A VM is certainly adequate for testing.
I have done some customization to my config, but I don't really think that's necessary for most small sites. It's certainly better then piecing together all the components yourself. The install package will provide you with a working postfix, dovecot, greylisting, clamav, spamassassin, spf etc and you can always add any additional postfix compatibile addons. The commercial version is still open source and gets a few extra features over the free version. I currently run the free version, but I like the author and plan to spring for the commercial version.
http://www.tummy.com/Products/vpostmaster
There are a 2 or 3 alternatives that provide an integrated mail system based on postfix. I looked at them a while back and all were less attractive to me. I'd have to dig up their names, but one is a package in the fedora repositories. I think it's written in java. Sounded like a nightmare to me.
Nataraj
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Mar 13, 2012, at 2:56 PM, Nataraj incoming-centos@rjl.com wrote:
For a small site it runs very well in a VM. A VM is certainly adequate for testing.
Hehe, I run my complete environment in a VM, it isn't the CPU/memory that limits VM deployments it's network/disk.
Got enough network and disk spindles and I can virtualize anything and make it run well.
-Ross
On Mar 13, 2012, at 10:02 AM, m.roth@5-cent.us wrote:
I'm just trying to think of ways around a blacklist... *esp* the way dnsorb does, where they'll blacklist an entire block that belongs to a hosting provider, who provides one external delivery address.
When I did spamassassin I relied on the content scores and bayesian database and it worked quite well after I culled a huge amount of example junk email and good email and fed it into the bayesian database (1000s of emails).
I have since bought Ironports as our needs grew. These use a shared reputation database between all Ironport customers that every appliance sends updates to and receives updates from based on "outbreak filters", which I suppose work like spamassassin's content scoring.
It would be nice if there was a shared bayesian database between all spamassassin users.
-Ross
On 12-03-12 22:12, Bob Hoffman wrote: [snip]
Not sure if this setup is perfect, but it is working quite well. Yes, the mail takes a few seconds longer and there is probably more I could do, but this ROCKS!!!
Totally agree. I'm definitely not a postfix expert but below I have listed some rules I have in my config.
smtpd_delay_reject = yes smtpd_helo_required = yes
I also have: disable_vrfy_command = yes strict_rfc821_envelopes = yes
smtpd_client_restrictions = permit_mynetworks,permit
In smtpd_client_restrictions I have:
smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unknown_reverse_client_hostname, check_client_access pcre:/etc/postfix/dynamic_ip_client_block, reject_rbl_client bl.spameatingmonkey.net, reject_rhsbl_sender uribl.spameatingmonkey.net, reject_rhsbl_client uribl.spameatingmonkey.net, reject_rhsbl_sender urired.spameatingmonkey.net, reject_rhsbl_client urired.spameatingmonkey.net, reject_rbl_client zen.spamhaus.org
The dynamic IP client list is quite effective. You can get the file: wget -v http://www.hardwarefreak.com/fqrdns.pcre
smtpd_helo_restrictions = permit_mynetworks, reject_non_fqdn_helo_hostname, reject_invalid_helo_hostname, permit
smtpd_sender_restrictions = permit_mynetworks, reject_non_fqdn_sender, reject_unknown_sender_domain, permit
In smtpd_sender_restrictions I also use
reject_rhsbl_sender fresh15.spameatingmonkey.net
smtpd_recipient_restrictions = reject_non_fqdn_recipient, reject_unknown_recipient_domain, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, reject_invalid_hostname, reject_unauth_pipelining, reject_rbl_client zen.spamhaus.org, reject_rbl_client truncate.gbudb.net, reject_rbl_client dnsbl.njabl.org reject_rbl_client cbl.abuseat.org reject_rbl_client bl.spamcop.net, reject_rbl_client dnsbl.sorbs.net, sleep 1, permit
smtpd_data_restrictions = permit_mynetworks, reject_multi_recipient_bounce, permit
Not sure if these rules are correct. I only have
smtpd_data_restrictions = reject_unauth_pipelining
On my CentOS 5 box I don't user "permit" at all.
Regards, Patrick
On Mon, 2012-03-12 at 23:15 +0100, Patrick Lists wrote:
On 12-03-12 22:12, Bob Hoffman wrote: [snip]
Not sure if this setup is perfect, but it is working quite well. Yes, the mail takes a few seconds longer and there is probably more I could do, but this ROCKS!!!
Totally agree. I'm definitely not a postfix expert but below I have listed some rules I have in my config.
smtpd_delay_reject = yes smtpd_helo_required = yes
I also have: disable_vrfy_command = yes strict_rfc821_envelopes = yes
smtpd_client_restrictions = permit_mynetworks,permit
In smtpd_client_restrictions I have:
smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unknown_reverse_client_hostname, check_client_access pcre:/etc/postfix/dynamic_ip_client_block, reject_rbl_client bl.spameatingmonkey.net, reject_rhsbl_sender uribl.spameatingmonkey.net, reject_rhsbl_client uribl.spameatingmonkey.net, reject_rhsbl_sender urired.spameatingmonkey.net, reject_rhsbl_client urired.spameatingmonkey.net, reject_rbl_client zen.spamhaus.org
The dynamic IP client list is quite effective. You can get the file: wget -v http://www.hardwarefreak.com/fqrdns.pcre
smtpd_helo_restrictions = permit_mynetworks, reject_non_fqdn_helo_hostname, reject_invalid_helo_hostname, permit
smtpd_sender_restrictions = permit_mynetworks, reject_non_fqdn_sender, reject_unknown_sender_domain, permit
In smtpd_sender_restrictions I also use
reject_rhsbl_sender fresh15.spameatingmonkey.net
smtpd_recipient_restrictions = reject_non_fqdn_recipient, reject_unknown_recipient_domain, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, reject_invalid_hostname, reject_unauth_pipelining, reject_rbl_client zen.spamhaus.org, reject_rbl_client truncate.gbudb.net, reject_rbl_client dnsbl.njabl.org reject_rbl_client cbl.abuseat.org reject_rbl_client bl.spamcop.net, reject_rbl_client dnsbl.sorbs.net, sleep 1, permit
smtpd_data_restrictions = permit_mynetworks, reject_multi_recipient_bounce, permit
Not sure if these rules are correct. I only have
smtpd_data_restrictions = reject_unauth_pipelining
On my CentOS 5 box I don't user "permit" at all.
Regards, Patrick _______________________________________________
I'm going to chuck in my 2 cents worth here, as I've been using Postfix as a first-line filter for some years now.
All of the above suggestions are very useful. The only point that I haven't seen in this thread is that mail server/filter configs are extremely user-dependent. I started out with some of the more restrictive options discussed here, but I had to relax a few of them for the client involved. It seems that they were doing business with some folks ( both customers and suppliers ) who were using poorly-configured mail servers, and some of the options given above can cause "legitimate" traffic from such poorly-configured servers to be rejected.
In short, like you should do for any application, do the appropriate research so that you UNDERSTAND what the recommended options are doing for you ( or TO you ) and tailor your selection(s) to meet YOUR specific needs. In the case of using Postfix to filter mail to reduce the inbound spam to an old, feature-poor mail server, it took some research and some experimenting with different recommendations to achieve the solution that met the needs of a particular user community.
Like I said, this is just my $0.02 (US) worth. Enjoy. ;^>
On 03/12/2012 09:08 PM, Ron Loftin wrote:
I'm going to chuck in my 2 cents worth here, as I've been using Postfix as a first-line filter for some years now.
All of the above suggestions are very useful. The only point that I haven't seen in this thread is that mail server/filter configs are extremely user-dependent. I started out with some of the more restrictive options discussed here, but I had to relax a few of them for the client involved. It seems that they were doing business with some folks ( both customers and suppliers ) who were using poorly-configured mail servers, and some of the options given above can cause "legitimate" traffic from such poorly-configured servers to be rejected.
In short, like you should do for any application, do the appropriate research so that you UNDERSTAND what the recommended options are doing for you ( or TO you ) and tailor your selection(s) to meet YOUR specific needs. In the case of using Postfix to filter mail to reduce the inbound spam to an old, feature-poor mail server, it took some research and some experimenting with different recommendations to achieve the solution that met the needs of a particular user community.
Like I said, this is just my $0.02 (US) worth. Enjoy. ;^>
Yes, this is very much true. It takes a bit of tuning to find the right settings for each mail environment. Turn things up too high and your phone will ring off the hook with user complaints about rejecting mail that they want to receive. Fortunately you can define multiple smtpd_restriction_classes and apply different policies by matching on who the recipient, sender, client domain etc is. An example would be:
NOTE THIS example is hypothetical, I don't suggest that anyone try to use my extra_restrictive class on a production system without testing.
smtpd_restriction_classes = extra_restrictive, restrictive, permissive
extra_restrictive = reject_rbl_client dul.dnsbl.sorbs.net reject_rbl_client zen.spamhaus.org reject_rbl_client bl.spamcop.net reject_rbl_client hostkarma.junkemailfilter.com =127.0.0.2 reject_rbl_client dnsbl.sorbs.net reject_rhsbl_sender whois.rfc-ignorant.org reject_rhsbl_sender postmaster.rfc-ignorant.org reject_rhsbl_sender abuse.rfc-ignorant.org reject_rhsbl_sender hostkarma.junkemailfilter.com=127.0.0.2 reject_rbl_client l2.apews.org
restrictive = reject_rbl_client zen.spamhaus.org reject_rbl_client bl.spamcop.net
permissive = reject_rbl_client pbl.spamhaus.org
smtpd_recipient_restrictions = permit_sasl_authenticated permit_mynetworks check_recipient_access proxy:pgsql:/etc/postfix/vpm_recipient_access ############################################## # NOTE: YOU MUST ALWAYS check for valid recipients before checking # for sender exceptions, otherwise anyone who passes the # sender exceptions will be allowed to use us as a relay. ############################################## check_sender_access hash:/etc/postfix/smtpd_sender_access check_recipient_access hash:/etc/postfix/smtpd_recipient_access check_policy_service unix:private/vpm-pfpolicy reject_unauth_destination
Then is smtpd_recipient_access I have:
domain1.com restrictive abuse@domain1.com extra_restrictive postmaster@domain1.com extra_restrictive registrar_domain_contact@domain1.com extra_restrictive domain2.com permissive
Nataraj
On 03/12/2012 10:06 PM, Nataraj wrote:
On 03/12/2012 09:08 PM, Ron Loftin wrote:
I'm going to chuck in my 2 cents worth here, as I've been using Postfix as a first-line filter for some years now.
All of the above suggestions are very useful. The only point that I haven't seen in this thread is that mail server/filter configs are extremely user-dependent. I started out with some of the more restrictive options discussed here, but I had to relax a few of them for the client involved. It seems that they were doing business with some folks ( both customers and suppliers ) who were using poorly-configured mail servers, and some of the options given above can cause "legitimate" traffic from such poorly-configured servers to be rejected.
In short, like you should do for any application, do the appropriate research so that you UNDERSTAND what the recommended options are doing for you ( or TO you ) and tailor your selection(s) to meet YOUR specific needs. In the case of using Postfix to filter mail to reduce the inbound spam to an old, feature-poor mail server, it took some research and some experimenting with different recommendations to achieve the solution that met the needs of a particular user community.
Like I said, this is just my $0.02 (US) worth. Enjoy. ;^>
pbl.spamhaus.org (dynamic IP address RBL) is generally quite safe for most sites to use from postfix. The rest of the spamhaus RBL's such as the combination that you get from zen.spamhaus.org are mostly safe (better than all others that I've tried), but not 100%. Most others that I've tried I have gotten a fair number of false positives over time (This includes dul.dnsbl.sorbs.net, the sorbs dynamic IP RBL). Many people feel that most other RBL's need to be used with a scoring mechanism, such as that provided by spamassasin, instead of directly from postfix to avoid getting too many false positives.
Nataraj
*Nataraj* /Tue Mar 13 02:01:36 EDT 2012/ wrote:
On 03/12/2012 10:06 PM, Nataraj wrote:
/ On 03/12/2012 09:08 PM, Ron Loftin wrote:
/>>>/ I'm going to chuck in my 2 cents worth here, as I've been using Postfix />>>/ as a first-line filter for some years now. // />pbl.spamhaus.org (dynamic IP address RBL) is generally quite safe for
most sites to use from postfix. The rest of the spamhaus RBL's such as the combination that you get from zen.spamhaus.org are mostly safe (better than all others that I've tried), but not 100%. Most others that I've tried I have gotten a fair number of false positives over time (This includes dul.dnsbl.sorbs.net, the sorbs dynamic IP RBL). Many people feel that most other RBL's need to be used with a scoring mechanism, such as that provided by spamassasin, instead of directly from postfix to avoid getting too many false positives.
Nataraj
I changed it a bit since then. I found that sleep 1, when talking to my other VM that had sleep 1, caused one mail to just get lost, so I dropped it.
My brother travels a lot and I found the client restrictions would not allow him to send mail since the wi-fi he would connect to was not figured correctly causing 100% mail send failure. So I left client restrictions empty, but I force ssl and user auth only anyway.
for the rbl lists I tried to pick those that had a notice page and a remove page. This way a blocked user can try to figure out why.
Here is a bit from my logwatch, with 8 hours of non blocked spam and 16 hours since blocking it 6098 rejected, 429 accepted (most of those 429 were before the change) Since 12 noon yesterday I have received 17 junk mails, all but two tagged by spamasassin. BIG DIFFERENCE.
Below is the logwatch section, followed by my final set up (at least so far).
1.062M Bytes accepted 1,113,084 1007.732K Bytes delivered 1,031,918 ======== ================================================
429 Accepted 6.57% 6098 Rejected 93.43% -------- ------------------------------------------------ 6527 Total 100.00% ======== ================================================
4 Reject relay denied 0.07% 340 Reject HELO/EHLO 5.58% 1749 Reject unknown user 28.68% 1 Reject recipient address 0.02% 3 Reject sender address 0.05% 4001 Reject RBL 65.61% -------- ------------------------------------------------ 6098 Total Rejects 100.00% ======== ================================================
8 4xx Reject relay denied 0.84% 318 4xx Reject HELO/EHLO 33.23% 39 4xx Reject unknown user 4.08% 81 4xx Reject recipient address 8.46% 511 4xx Reject sender address 53.40% -------- ------------------------------------------------ 957 Total 4xx Rejects 100.00% ======== ================================================
3534 Connections made 419 Connections lost 3533 Disconnections 429 Removed from queue 137 Delivered 10 Sent via SMTP 1 Bounce (remote) 1 DSNs undeliverable
22 Connection failure (outbound) 23 Timeout (inbound) 1 RBL lookup error 35 Excessive errors in SMTP commands dialog 802 Hostname verification errors 89 Address is deliverable (sendmail -bv) 194 Address is undeliverable (sendmail -bv) 4 Enabled PIX workaround 9 SASL authenticated messages
7 Postfix start 7 Postfix stop 4 Postfix refresh
# for SMTP-Auth settings
smtpd_sasl_type = dovecot smtpd_sasl_path = private/auth smtpd_sasl_auth_enable = yes smtpd_sasl_security_options = noanonymous smtpd_sasl_local_domain = $myhostname
smtpd_delay_reject = yes smtpd_helo_required = yes
smtpd_client_restrictions = permit_mynetworks
smtpd_helo_restrictions = permit_mynetworks, reject_non_fqdn_helo_hostname, reject_invalid_helo_hostname
smtpd_sender_restrictions = permit_mynetworks, reject_non_fqdn_sender, reject_unknown_sender_domain
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, reject_unauth_pipelining, reject_non_fqdn_recipient, reject_unknown_recipient_domain, reject_invalid_hostname, reject_unknown_hostname, reject_non_fqdn_hostname reject_rbl_client zen.spamhaus.org, reject_rbl_client truncate.gbudb.net, reject_rbl_client dnsbl.njabl.org reject_rbl_client cbl.abuseat.org reject_rbl_client bl.spamcop.net, reject_rbl_client dnsbl.sorbs.net, reject_unverified_recipient
smtpd_data_restrictions = permit_mynetworks, reject_multi_recipient_bounce smtpd_use_tls = yes smtpd_tls_cert_file = /etc/pki/dovecot/certs/dovecot.pem smtpd_tls_key_file = /etc/pki/dovecot/private/dovecot.pem
On 03/13/2012 04:21 AM, Bob Hoffman wrote:
*Nataraj* /Tue Mar 13 02:01:36 EDT 2012/ wrote:
On 03/12/2012 10:06 PM, Nataraj wrote:
/ On 03/12/2012 09:08 PM, Ron Loftin wrote:
/>>>/ I'm going to chuck in my 2 cents worth here, as I've been using Postfix />>>/ as a first-line filter for some years now. // />pbl.spamhaus.org (dynamic IP address RBL) is generally quite safe for
most sites to use from postfix. The rest of the spamhaus RBL's such as the combination that you get from zen.spamhaus.org are mostly safe (better than all others that I've tried), but not 100%. Most others that I've tried I have gotten a fair number of false positives over time (This includes dul.dnsbl.sorbs.net, the sorbs dynamic IP RBL). Many people feel that most other RBL's need to be used with a scoring mechanism, such as that provided by spamassasin, instead of directly from postfix to avoid getting too many false positives.
Nataraj
I changed it a bit since then. I found that sleep 1, when talking to my other VM that had sleep 1, caused one mail to just get lost, so I dropped it.
My brother travels a lot and I found the client restrictions would not allow him to send mail since the wi-fi he would connect to was not figured correctly causing 100% mail send failure. So I left client restrictions empty, but I force ssl and user auth only anyway.
Mobile clients should be authenticating to a relay that's not on any of the dynamic lists and sending mail out through there. Most sane mail administrators do not accept mail directly from dynamic broadband/mobile clients.
for the rbl lists I tried to pick those that had a notice page and a remove page. This way a blocked user can try to figure out why.
Also anyone using rbl's should also review the RBL's policy. Most RBL's charge a license fee for high volume queries and will cut you off if you violate their policy.
Here is a bit from my logwatch, with 8 hours of non blocked spam and 16 hours since blocking it 6098 rejected, 429 accepted (most of those 429 were before the change) Since 12 noon yesterday I have received 17 junk mails, all but two tagged by spamasassin. BIG DIFFERENCE.
Below is the logwatch section, followed by my final set up (at least so far).
Your logwatch format is very nice, that does not appear to be the standard CentOS included logwatch. Have you customized it alot yourself?
In any case, I used to have very large numbers in the category you described, but since I started doing agressive blocking with fail2ban (matching on repeated mail delivery failures), now I just completely block all those with IPtables, so that postfix never sees them. I have not noticed any increase in user complaints since this happened. And I do notice that the majority of the offending IP addresses were from asia, south america, eastern Europe, the middle east, etc.
Is this just a personal mail server or are you serving a large user base?
1.062M Bytes accepted 1,113,0841007.732K Bytes delivered 1,031,918 ======== ================================================
429 Accepted 6.57% 6098 Rejected 93.43%
6527 Total 100.00%======== ================================================
4 Reject relay denied 0.07% 340 Reject HELO/EHLO 5.58% 1749 Reject unknown user 28.68% 1 Reject recipient address 0.02% 3 Reject sender address 0.05% 4001 Reject RBL 65.61%
6098 Total Rejects 100.00%======== ================================================
8 4xx Reject relay denied 0.84% 318 4xx Reject HELO/EHLO 33.23% 39 4xx Reject unknown user 4.08% 81 4xx Reject recipient address 8.46% 511 4xx Reject sender address 53.40%
957 Total 4xx Rejects 100.00%======== ================================================
3534 Connections made 419 Connections lost 3533 Disconnections 429 Removed from queue 137 Delivered 10 Sent via SMTP 1 Bounce (remote) 1 DSNs undeliverable 22 Connection failure (outbound) 23 Timeout (inbound) 1 RBL lookup error 35 Excessive errors in SMTP commands dialog 802 Hostname verification errors 89 Address is deliverable (sendmail -bv) 194 Address is undeliverable (sendmail -bv) 4 Enabled PIX workaround 9 SASL authenticated messages 7 Postfix start 7 Postfix stop 4 Postfix refresh# for SMTP-Auth settings
smtpd_sasl_type = dovecot smtpd_sasl_path = private/auth smtpd_sasl_auth_enable = yes smtpd_sasl_security_options = noanonymous smtpd_sasl_local_domain = $myhostname
smtpd_delay_reject = yes smtpd_helo_required = yes
smtpd_client_restrictions = permit_mynetworks
smtpd_helo_restrictions = permit_mynetworks, reject_non_fqdn_helo_hostname, reject_invalid_helo_hostname
smtpd_sender_restrictions = permit_mynetworks, reject_non_fqdn_sender, reject_unknown_sender_domain
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, reject_unauth_pipelining, reject_non_fqdn_recipient, reject_unknown_recipient_domain, reject_invalid_hostname, reject_unknown_hostname, reject_non_fqdn_hostname reject_rbl_client zen.spamhaus.org, reject_rbl_client truncate.gbudb.net, reject_rbl_client dnsbl.njabl.org reject_rbl_client cbl.abuseat.org reject_rbl_client bl.spamcop.net, reject_rbl_client dnsbl.sorbs.net, reject_unverified_recipient
smtpd_data_restrictions = permit_mynetworks, reject_multi_recipient_bounce
smtpd_use_tls = yes smtpd_tls_cert_file = /etc/pki/dovecot/certs/dovecot.pem smtpd_tls_key_file = /etc/pki/dovecot/private/dovecot.pem
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Nataraj wrote: <snip>
In any case, I used to have very large numbers in the category you described, but since I started doing agressive blocking with fail2ban (matching on repeated mail delivery failures), now I just completely block all those with IPtables, so that postfix never sees them. I have not noticed any increase in user complaints since this happened. And I do notice that the majority of the offending IP addresses were from asia, south america, eastern Europe, the middle east, etc.
<snip> Yeah, I'd love to find a way to create a filter, maybe in t-bird, that deleted any email whose subject line content was non-ASCII. I *know* they're not for me....
mark "and I'm always insulted if they're not offering me at *least* $25M USD"
*Nataraj* /Tue Mar 13 13:17:32 EDT 2012 wrote
========================================== /
<snip> Also anyone using rbl's should also review the RBL's policy. Most RBL's charge a license fee for high volume queries and will cut you off if you violate their policy. <snip> <snip> our logwatch format is very nice, that does not appear to be the standard CentOS included logwatch. Have you customized it alot yourself? <snip> <snip> Is this just a personal mail server or are you serving a large user base? <snip> =================================================
You can also work out something with the RBLs if you are large enough, to download their database in some way, and update through that method, while somehow using your own files/database through postfix (or whatever mail server)
The logwatch format looks groovy for two reasons, 1- it is centos 6 version, 2- it is on HIGH detail (or 10, whichever you prefer)
This is just one address on a personal server. Just me. This is an address I have had since 2002 and was quite active online. My other address is from 1997 and it is insane the amount of junk.
Still getting a small amount through. My next step is to get procmail to /dev/null according to spam-level from spamassassin...so I may have it set at 5 to tag as spam, but procmail can look at the level somehow and if I say 'greater than 15' /devnull.
will figure it out.
On Tue, 2012-03-13 at 15:48 -0400, Bob Hoffman wrote:
Still getting a small amount through. My next step is to get procmail to /dev/null according to spam-level from spamassassin...so I may have it set at 5 to tag as spam, but procmail can look at the level somehow and if I say 'greater than 15' /devnull.
will figure it out.
Add postgrey to your setup. Your spam should drop to nothing (well, so near to nothing it makes no difference).
Regards,
Ranbir
On Mon, 12 Mar 2012 17:12:13 -0400 Bob Hoffman bob@bobhoffman.com wrote:
On my centos 5 server I just used sendmail with spamassassin and it killed a lot. Still, 100s, sometimes more made it through. Then thunderbird would weed out more, learned as it went... Still, had an inbox with a lot of junk.
Maybe you should read some http://www.acme.com/mail_filtering/ ... altough from 2005, one of the best sendmail writeups I'm aware of.
Now I have set up a centos 6 box using postfix. Today I decided to try to add smtpd restrictions. After a lot of reading and testing I 'seem' to be doing incredible.
I've switched to postfix back in 2001 and yes, it is amazing. Now that you're free of spam, you can dive into policyd and various content filtering schemes available. It's amazing how far email has come, yet it's even more amazing that none of the major linux distros have everything in one place, well integrated and polished and we poor sysadmins still have to stich solutions together ... heck, I still have to patch sasl for it to auth against crypted passwords ... maybe I should stop before I start ranting ;)
on/Mon Mar 12 18:39:23 EDT 2012 Jure Pecar wrote /========================================================== /On Mon, 12 Mar 2012 17:12:13 -0400 /Bob Hoffman<bob at bobhoffman.com http://lists.centos.org/mailman/listinfo/centos> wrote:
/>/ On my centos 5 server I just used sendmail with spamassassin and it //>/ killed a lot. Still, 100s, sometimes more made it through. Then //>/ thunderbird would weed out more, learned as it went... //>/ Still, had an inbox with a lot of junk. / /Maybe you should read somehttp://www.acme.com/mail_filtering/ ... altough /from 2005, one of the best sendmail writeups I'm aware of.
/>/ Now I have set up a centos 6 box using postfix. Today I decided to try //>/ to add smtpd restrictions. After a lot of reading and testing I 'seem' /// to be doing incredible. / /I've switched to postfix back in 2001 and yes, it is amazing. Now that /you're free of spam, you can dive into policyd and various content /filtering schemes available. It's amazing how far email has come, yet it's /even more amazing that none of the major linux distros have everything in /one place, well integrated and polished and we poor sysadmins still have to /stich solutions together ... heck, I still have to patch sasl for it to /auth against crypted passwords ... maybe I should stop before I start /ranting ;) =============================================================
yea, it would only accept normal passwords, but I figured since it was using tls/ssl that the whole shebang was encypted anyway so it should be fine, right?
Also, still getting spam of course, nut a smidgeon compared to before. I would say 99.9% is being tagged by spam assassin as [spam]. Still afraid of false positives so gonna watch for a while with spamassassin before I dev null them buggers.
On Mon, 2012-03-12 at 23:39 +0100, Jure Pečar wrote:
On Mon, 12 Mar 2012 17:12:13 -0400 Bob Hoffman bob@bobhoffman.com wrote:
On my centos 5 server I just used sendmail with spamassassin and it killed a lot. Still, 100s, sometimes more made it through. Then thunderbird would weed out more, learned as it went... Still, had an inbox with a lot of junk.
Maybe you should read some http://www.acme.com/mail_filtering/ ... altough from 2005, one of the best sendmail writeups I'm aware of.
+1 I've owned/used awilliam@whitemice.org for decades. There it is - I've *never* engaged in stupid address obscurity schemes. I get at most four or five SPAM messages in my INBOX each day. A proper configuration works very well.
Now I have set up a centos 6 box using postfix. Today I decided to try to add smtpd restrictions. After a lot of reading and testing I 'seem' to be doing incredible.
I've switched to postfix back in 2001 and yes, it is amazing. Now that you're free of spam, you can dive into policyd and various content filtering schemes available. It's amazing how far email has come, yet it's even more amazing that none of the major linux distros have everything in one place, well integrated and polished and we poor sysadmins still have to stich solutions together ...
+1
Configure Postfix Configure CLAM [this doesn't even include any usable scripts] (1) Configure SPAMassassin Integrate the three Troubleshoot
You can throw a couple of RBLs or even greylist in there too.
It does seem like this should be out-of-the box on this point.
(1) I've written most of my config up in the Postfix chapter of http://bit.ly/exQSCH
heck, I still have to patch sasl for it to auth against crypted passwords ... maybe I should stop before I start ranting ;)
On Tue, 13 Mar 2012 08:53:06 -0400 Adam Tauno Williams awilliam@whitemice.org wrote:
Now I have set up a centos 6 box using postfix. Today I decided to try to add smtpd restrictions. After a lot of reading and testing I 'seem' to be doing incredible.
I've switched to postfix back in 2001 and yes, it is amazing. Now that you're free of spam, you can dive into policyd and various content filtering schemes available. It's amazing how far email has come, yet it's even more amazing that none of the major linux distros have everything in one place, well integrated and polished and we poor sysadmins still have to stich solutions together ...
+1
Configure Postfix Configure CLAM [this doesn't even include any usable scripts] (1) Configure SPAMassassin Integrate the three Troubleshoot
You can throw a couple of RBLs or even greylist in there too.
It does seem like this should be out-of-the box on this point.
Then add user management, webmail, webmail extensions that enable users to manage their own settings, antispam policies, vacations, addressbooks and whatnot.
Then add monitoring and abuse handling, support staf interface, accounting and billing.
Then make all this work thru some stupid braindead phone thingy.
If you can get some quality sleep after that, you win.
Hiring mail services from "the cloud" is such a no-brainer these days ...
On Tue, Mar 13, 2012 at 9:43 AM, Jure Pečar pegasus@nerv.eu.org wrote:
It does seem like this should be out-of-the box on this point.
Then add user management, webmail, webmail extensions that enable users to manage their own settings, antispam policies, vacations, addressbooks and whatnot.
I think you just described ClearOS....
From: Les Mikesell lesmikesell@gmail.com
Then add user management, webmail, webmail extensions that enable users to
manage their own settings, antispam policies, vacations, addressbooks and whatnot.
I think you just described ClearOS....
Or Zimbra...
JD
On Wed, Mar 14, 2012 at 9:10 AM, John Doe jdmls@yahoo.com wrote:
From: Les Mikesell lesmikesell@gmail.com
Then add user management, webmail, webmail extensions that enable users to
manage their own settings, antispam policies, vacations, addressbooks and whatnot.
I think you just described ClearOS....
Or Zimbra...
This was in the context of things working 'out-of-the-box' in a base install. Does any distribution ship with zimbra configured?
From: Les Mikesell lesmikesell@gmail.com
This was in the context of things working 'out-of-the-box' in a base install. Does any distribution ship with zimbra configured?
Not sure how far out-of-the-box goes but: Not free: "The Zimbra Collaboration Server Appliance is the Zimbra email and collaboration solution delivered as a VMware virtual appliance." The free open source edition is not too complicated to install (even I could do it ;) - Download big tgz - Extract big tgz - Run install script and answer a few questions. => Everything installed in /opt/zimbra It uses its own postfix/cyrus/clamav/mysql/httpd/ldap/java... The upside is that everything component is already setup to work fine with each other. The downside is that it feels like a big huge blackbox that seem to work fine so far, and you are dependent on VMware for security updates... Of course, you still need to tweak the conf for things like: - adding specific SSL keys - binding only on a specific IP - authorize relaying - etc... Configuration seems to be totally scriptable. But I had to create scripts for automated backups (full, users mailboxes, mysql, ldap). So far so good (need quite some RAM thx to java). But I do not have many mailboxes (less than 100) and so went with the simple standalone setup.
JD
-
Adam Tauno Williams -
Bob Hoffman -
John Doe -
Jure Pečar -
Kanwar Ranbir Sandhu -
Les Mikesell -
m.roth＠5-cent.us -
Nataraj -
Patrick Lists -
Ron Loftin -
Ross Walker -
Stephen Harris -
Tom Bishop