We have our setup documented. I'll pull out the stuff for our environment and send over something more general. It may take a few hours before I get time though.

Adam King IT Systems Administrator Skipton Girls High School 01756 707600 www.sghs.org.uk

----- Original Message ----- From: "Alexander Farber" alexander.farber@gmail.com To: "CentOS mailing list" centos@centos.org Sent: Monday, August 11, 2014 12:47:21 PM Subject: Re: [CentOS] Use postfix and spamd on CentOS 6 - looking for a shortest guide

Hi Adam,

there is no "spamd.conf" file in the spamassassin package for CentOS 6:

# rpm -ql spamassassin|grep -i spamd.conf #

That's the point of my question: I am looking for advice for how to use the "postfix" and "spamassassin" packages - i.e. not installing both programs manually "from scratch".

(Unless I have misunderstood your question, then I am sorry).

Regards Alex

On Mon, Aug 11, 2014 at 1:04 PM, Adam King kinga@sghs.org.uk wrote:

whats your database user in spamd.conf?

----- Original Message ----- From: "Alexander Farber" alexander.farber@gmail.com

So I have installed the both packages and I have configured postfix (it works fine).

Also I have started the spamd (and can see it in "ps uawx") with:

# chkconfig spamassassin on
# service spamassassin start

So I'm just missing the connection between postfix and spamd.

Could anybody using these 2 programs on CentOS 6 please share it with me?

Should I add something (involving spamc?) into /etc/postfix/master.cf? .....

P.S. Below is my "postconf -n". I accept mails (here I'd like to filter spam) for 6 virtual domains and then forward them to different GMail accounts:

alias_database = hash:/etc/aliases

alias_maps = hash:/etc/aliases

command_directory = /usr/sbin

config_directory = /etc/postfix

daemon_directory = /usr/libexec/postfix

data_directory = /var/lib/postfix

debug_peer_level = 2

header_checks = pcre:/etc/postfix/header_checks

html_directory = no

inet_interfaces = all

inet_protocols = ipv4

mail_owner = postfix

mailq_path = /usr/bin/mailq.postfix

manpage_directory = /usr/share/man

mydestination = $myhostname, localhost.$mydomain, localhost

myhostname = www.afarber.de

newaliases_path = /usr/bin/newaliases.postfix

queue_directory = /var/spool/postfix

readme_directory = /usr/share/doc/postfix-2.6.6/README_FILES

sample_directory = /usr/share/doc/postfix-2.6.6/samples

sendmail_path = /usr/sbin/sendmail.postfix

setgid_group = postdrop

smtp_destination_concurrency_limit = 2

smtp_destination_rate_delay = 40s

smtp_generic_maps = hash:/etc/postfix/generic

unknown_local_recipient_reject_code = 550

virtual_alias_domains = videoskat.de balkan-preferans.de simplex.ru larissa-farber.de bukvy.de slova.de

virtual_alias_maps = hash:/etc/postfix/virtual _______________________________________________ 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

Hello again, here is what I'm trying at my CentOS 6.5:

1) Installed postfix and spamassassin packages 2) Configured postfix - it works well (I omit details here) 3) Added "-x" to the SPAMDOPTIONS in /etc/sysconfig/spamassassin 4) Added the following 2 lines to the /etc/postfix/master.cf:

smtp inet n - n - - smtpd -o content_filter=spamassassin spamassassin unix - n n - - pipe user=nobody argv=/usr/bin/spamc -f -e /usr/sbin/sendmail -oi -f ${sender} ${recipient}

Unfortunately, when I send the test SPAM mail with the subject XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X

- it still comes through! (And the subject isn't rewritten).

I wonder, what have I missed? My /var/log/maillog is below.

I've also asked my question at http://serverfault.com/questions/619537/use-postfix-and-spamassassin-package...

Regards Alex

postfix/postfix-script[2546]: starting the Postfix mail system postfix/master[2547]: daemon started -- version 2.6.6, configuration /etc/postfix postfix/qmgr[2550]: D5B19807033: from=bsdglVlCWcQAM@yandex.ru, size=1843, nrcpt=1 (queue active) postfix/qmgr[2550]: 831CA809733: from=equipmentsup@saic.com, size=41369, nrcpt=1 (queue active) postfix/qmgr[2550]: 42B7A80A312: from=minzhigroup55@minzhigroup.vicp.cc, size=4399, nrcpt=1 (queue active) postfix/qmgr[2550]: AED94809D29: from=marketing@groupmenumagazine.co.uk, size=28035, nrcpt=1 (queue active) postfix/qmgr[2550]: E69AA809D3C: from=<>, size=3487, nrcpt=1 (queue active) postfix/qmgr[2550]: 2BDE980A61B: from=haky151@yahoo.co.jp, size=4073, nrcpt=1 (queue active) postfix/qmgr[2550]: 0D37280A51F: from=info@c21.com, size=7888, nrcpt=1 (queue active) postfix/smtp[2552]: D5B19807033: host gmail-smtp-in.l.google.com[74.125.136.27] said: 421-4.7.0 [144.76.184.154 15] Our system has detected an unusual rate of 421-4.7.0 unsolicited mail originating from your IP address. To protect our 421-4.7.0 users from spam, mail sent from your IP address has been temporarily 421-4.7.0 rate limited. Please visit 421-4.7.0 http://www.google.com/mail/help/bulk_mail.html to review our Bulk 421 4.7.0 Email Senders Guidelines. l16si23407549wjr.0 - gsmtp (in reply to end of DATA command) postfix/smtp[2552]: D5B19807033: to=Abram.Farber@gmail.com, orig_to=< simplex@simplex.ru>, relay=alt1.gmail-smtp-in.l.google.com[74.125.25.27]:25, delay=6325, delays=6323/0/1.2/0.61, dsn=4.7.0, status=deferred (host alt1.gmail-smtp-in.l.google.com[74.125.25.27] said: 421-4.7.0 [144.76.184.154 15] Our system has detected an unusual rate of 421-4.7.0 unsolicited mail originating from your IP address. To protect our 421-4.7.0 users from spam, mail sent from your IP address has been temporarily 421-4.7.0 rate limited. Please visit 421-4.7.0 http://www.google.com/mail/help/bulk_mail.html to review our Bulk 421 4.7.0 Email Senders Guidelines. f7si4794087pdm.22 - gsmtp (in reply to end of DATA command)) postfix/smtpd[2557]: connect from mail-ie0-f180.google.com[209.85.223.180] postfix/smtpd[2557]: B3FFF809367: client=mail-ie0-f180.google.com [209.85.223.180] postfix/cleanup[2561]: B3FFF809367: message-id=<CAADeyWgi9VjXoXoUXtTf0n4jp_WJzMd2q7C7zqkRpK7= eKhNGQ@mail.gmail.com> postfix/qmgr[2550]: B3FFF809367: from=alexander.XXX@gmail.com, size=1767, nrcpt=1 (queue active) spamd[2034]: spamd: connection from localhost [127.0.0.1] at port 42928 spamd[2034]: spamd: setuid to nobody succeeded spamd[2034]: spamd: processing message CAADeyWgi9VjXoXoUXtTf0n4jp_WJzMd2q7C7zqkRpK7=eKhNGQ@mail.gmail.com for nobody:99 postfix/smtpd[2557]: disconnect from mail-ie0-f180.google.com [209.85.223.180] spamd[2034]: spamd: identified spam (999.9/5.0) for nobody:99 in 0.2 seconds, 1730 bytes. spamd[2034]: spamd: result: Y 999 - DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,GTUBE,HTML_MESSAGE,T_TO_NO_BRKTS_FREEMAIL scantime=0.2,size=1730,user=nobody,uid=99,required_score=5.0,rhost=localhost,raddr=127.0.0.1,rport=42928,mid=<CAADeyWgi9VjXoXoUXtTf0n4jp_WJzMd2q7C7zqkRpK7= eKhNGQ@mail.gmail.com>,autolearn=no postfix/pickup[2549]: 3124F80A3DA: uid=99 from=alexander.XXX@gmail.com postfix/cleanup[2561]: 3124F80A3DA: message-id=<CAADeyWgi9VjXoXoUXtTf0n4jp_WJzMd2q7C7zqkRpK7= eKhNGQ@mail.gmail.com> postfix/pipe[2562]: B3FFF809367: to=Alexander.Farber@gmail.com, orig_to=< webmaster@bukvy.de>, relay=spamassassin, delay=0.59, delays=0.37/0.01/0/0.22, dsn=2.0.0, status=sent (delivered via spamassassin service) postfix/qmgr[2550]: B3FFF809367: removed spamd[2032]: prefork: child states: II postfix/qmgr[2550]: 3124F80A3DA: from=alexander.XXX@gmail.com, size=2843, nrcpt=1 (queue active)

Can you explain why you'd use milter over spamassassin? Genuinely interested as we could certainly get better spam filtering...

Adam King IT Systems Administrator Skipton Girls High School 01756 707600 www.sghs.org.uk

----- Original Message ----- From: "Alexander Dalloz" ad+lists@uni-x.org To: "CentOS mailing list" centos@centos.org Sent: Monday, 11 August, 2014 5:01:16 PM Subject: Re: [CentOS] Use postfix and spamd on CentOS 6 - looking for a shortest guide

Am 2014-08-11 13:38, schrieb Alexander Farber:

Hello fellow CentOS-users,

on the net there are lots of Spamassassin related HOWTOs - describing how to create a shell script for Postfix and how to install Spamassassin and start its spamd daemon - step by step. Additionally antivirus setups are described...

But I have a strong feeling, that this is unneeded on CentOS 6 - because there are already preconfigured stock packages for postfix and spamassassin.

So I have installed the both packages and I have configured postfix (it works fine).

Also I have started the spamd (and can see it in "ps uawx") with:

# chkconfig spamassassin on
# service spamassassin start

So I'm just missing the connection between postfix and spamd.

Could anybody using these 2 programs on CentOS 6 please share it with me?

[ ... ]

Do yourself a favour and use a milter instead of piping each single mail through spamassassin.

http://pkgs.org/centos-6/epel-x86_64/spamass-milter-0.3.2-3.el6.x86_64.rpm.h...

Then add something like

smtpd_milters = unix:/var/run/spamass-milter/postfix/sock inet:127.0.0.1:8891 non_smtpd_milters = $smtpd_milters milter_default_action = accept

to your Postfix' main.cf and configure the milter flags in /etc/sysconfig/spamass-milter.

Thank you Alex

[ ... ]

Alexander

_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

Valeri Galtsev wrote:

while you haven't settled on anything you could consider amavisd as well...

I'm using amavisd on a CentOS-6 server (with dovecot and spamassassin) but I found it very difficult to setup. The documentation for amavisd under CentOS is unbelievably bad. In fact, the documentation on using postfix and postfix-related packages under Linux is beginning to rival that for sendmail when it first came out, before someone wrote sendmail.mc .

There are innumerable recipes involving bizarre (and unexplained) additions to main.cf and master.cf (in /etc/postfix/). I asked about one such recipe, and was advised that I would have to read 2 books on postfix before I could understand it.

I've never seen a 1-page document that said, "These are the changes I made after downloading packages X, Y and Z." And there are few if any tests to determine where email is going if it is not going where you want it to.

BC wrote:

...

I've never seen a 1-page document that said, "These are the changes I made after downloading packages X, Y and Z."

There is a large chasm between configuring a mail server and understanding the configuration of a mail server. Due to the many pitfalls and custom environments, it is very difficult to have a 1-page document that does much more than be an outbound MTA.

Note what I asked for. If you have installed postfix + spamassassin or whatever under CentOS then presumably you downloaded certain packages and then made certain changes in config files and perhaps elsewhere. Therefore it is possible to write a short document just listing the changes you have made. It may be a waste of time in your view; but in my experience this is exactly what I want to read for my very basic home server needs.

Unlike apache, you can't just tweak the config after a failure and hit 'refresh'.

I don't see why not. That is exactly what I do, in both cases. The difference in my experience is that apache documentation is much better.

The postfix documentation does detail a few sane defaults, but spamassassin is not part of postfix and therefore the defaults have to be modified right from the get-go, also unlike with apache where the defaults work for many people because they don't require any complexity from their httpd servers.

MySQL, LDAP, PHP, etc, are not part of httpd, but they all seem to me to work well together without studying the matter in depth.

I would highly recommend getting a book on postfix.

If I had to read a book in order to install and configure postfix I would go back to sendmail.

You sound as though you think it is meritorious for software to be difficult to use. The task of postfix seems to me fairly easy to understand, so I don't see why implementing a solution should be that difficult.

On Wed, Aug 13, 2014 at 11:50 AM, Always Learning centos@u62.u22.net wrote:

No one really wants to revert to Sendmail - do they ?

I've always liked MimeDefang with sendmail - and these days it should be possible to make it work with postfix. Basically you connect it as a milter to the stock MTA - without many other config changes there. Then you add all of the scanning and control steps in a small snippet of perl (with examples available for most of the things you would want to do).

I'd recommend glancing through this document: http://www.mimedefang.org/static/mimedefang-lisa04.pdf for an overview of what you need to do even if you decide to use other tools. But, mimedefang is very effecient, at least with sendmail because it will unpack attachments once even if you do a number of different scans for spam/viruses, etc., and it hooks the milter interfaces for each operation separately through a multiplexer so you don't start a big perl process for every deliver and you don't keep it tied up for the steps that don't need it (see diagrams on pgs 16 and 113 of that pdf for the concept).

On Wed, 2014-08-13 at 19:32 +0200, Timothy Murphy wrote:

Always Learning wrote:

...

No one really wants to revert to Sendmail - do they ?

It worked fine for me for years - what do you have against it?

Sendmail lacks the configurability of Exim.

I can refuse connections if the sender's host name resembles a home Internet connection (contains dyn* static nnn-nnn-nnn-nnn or nnn.nnn.nnn.nnn or is on the list of home-type hosts such as *dsl.bell.ca etc. etc.)

I refuse connections when the HELO / EHLO does not resolve to the sender's IP address, for example

Sender's IP : 62.25.80.157 = mail1.bemta105.messagelabs.com Host name : mail1.bemta105.messagelabs.com = 62.25.80.157 HELO name : server-12.bemta-105.messagelabs.com = no IP address Date : Tuesday, 11:04, 12 August 2014, (+01:00)

Sender's IP : 202.94.83.220 = 202-94-83-220.infra.usd.ac.id Host name : 202-94-83-220.infra.usd.ac.id = 202.94.83.220 HELO name : ASRI-PC = no IP address Date : Wednesday, 06:16, 13 August 2014, (+01:00)

I can restrict sending to some email addresses to white-listed senders.

I can get rid of pests by rejecting with a bounce message 'the recipient's mail box is full'.

I can run a basic mailing list, within Exim, without having to use Mailman.

Just a few bits of basic care can dramatically restrict, if not virtually stop, spam and the inevitable viruses sent in spam.

I like Exim because it works well for me and it is reliable.

When I started using it, before sendmail.mc was introduced, I found it even more difficult to configure than postfix today.

What is really needed is a Plain Man's Guide to basic mail server operation. Describe the principles and how they are implemented on one's chosen mail server. Easy task to do, but I lack the time.

On Wed, August 13, 2014 11:50 am, Always Learning wrote:

On Wed, 2014-08-13 at 18:32 +0200, Timothy Murphy wrote:

...

If I had to read a book in order to install and configure postfix I

would go back to sendmail.

No one really wants to revert to Sendmail - do they ?

Sendmail exists forever. Postfix emerged a bit later, and postfix was written with security in mind. In case of sendmail on [huge] binary does everything, including listening to external port. There are quite likely multible bugs in large code. In case of postfix it is tiny piece of code (so there is virtually impossible to introduce bug into it) that listens to external ports. I was extremely happy to switch away from sendmail to postfix (and postfix configuration files are human readable!).

Usually postfix comes more or less decently configured as a trivial mail server (both in case of CentOS rpm, and from postfix vendor if you download tarball and build it yourself - I probably should mention the author: Vietse Venema), you will need to make postfix listen to external connections though in main.cf. I can not compare postfix to exim, I never used exim.

Building decent mail server with good spam filtering is different story, and requires some system administration knowledge. That is the reason for long replies that didn't appeal to you. RHEL is not there yet to claim as M$ does that you just get their product, few clicks and you have enterprise level [whichever service] and all auto-magically will work [thanks to RHEL and/or M$ great product]. They (RH) may be aiming to have it that way. If they succeed, anybody without special knowledge will be able to set up great Linux server, I guess. But, as I've heard once: "if even an idiot can use something only an idiot will use it". We'll see ;-)

Valeri

++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++

On Wed, August 13, 2014 12:45 pm, Kirk Bocek wrote:

On 8/13/2014 10:35 AM, Valeri Galtsev wrote:

...

Sendmail exists forever. ... I was extremely happy to switch away from sendmail to postfix (and postfix configuration files are human readable!).

Sendmail's heritage reaches back to when computer's were the size of dishwashers and had 4k of main memory. Hence the inscrutable syntax.

Of course, I used exaggeration (we all had "configure sendmail" chapter in our sysadmin exam back then). After you compile human readable sendmail config file into what sendmail uses, you get something similar to assembly code as opposed to high level programming language. And some of us were able to digest that too (as sometimes you inherit this file, but not the configuration source file)...

++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++

On 8/13/2014 10:57 AM, Valeri Galtsev wrote:

Of course, I used exaggeration (we all had "configure sendmail" chapter in our sysadmin exam back then). After you compile human readable sendmail config file into what sendmail uses, you get something similar to assembly code as opposed to high level programming language. And some of us were able to digest that too (as sometimes you inherit this file, but not the configuration source file)...

the M4 macro compiler came fairly late in Sendmail's evolution. in the OLD days, editing the sendmail.cf file directly was all you had. you just about needed a PhD in that stuff to do anything beyond the simplest tweaks, although with the O'Reilly Sendmail book ("bat book"), you could get away with assembling bits and pieces of other peoples hacks for most any sane configuration.

On 2014-08-13, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:

...

Building decent mail server with good spam filtering is different story, and requires some system administration knowledge.

Building a decent public SMTP server with good spam filtering *that does not originate spam itself* and *does not silently lose mail* is a hugely different story, and requires more than simply "some system administration knowledge". It requires a solid understanding of SMTP as well as the software involved, some knowledge of IP networks and DNS, and constant vigilance on the anti-spam sites to ensure you're not originating spam. Someone unable or unwilling to do these things should not expose their SMTP server to the public.

--keith

BC wrote:

...

The task of postfix seems to me fairly easy to understand, so I don't see why implementing a solution should be that difficult.

It seems easy to understand because you do not understand it. The more you delve into the topic of mail, the more you realize it is not easy to understand with just a few passing glances.

You should read more carefully. I said the _task_ of postfix is fairly easy to understand. Many problems are easy to understand but difficult to solve. What exactly is difficult to understand about the task of postfix?

Perhaps that is why you are not finding a simple document to answer your question.

Again, you should read more carefully what I asked for, namely a 1-page document stating (for a given installer) exactly what packages were installed, and what changes were made to the given config (and perhaps other) files.

Either way, I had no intention of making you mad. I was simply trying to help by saying that reading a book on postfix is a very worthwhile pursuit.

Not for me. We are inundated today with an avalanche of information. We are told far too much about everything. The true educators are those who filter out the essential core.

On 2014-08-13, Timothy Murphy gayleard@alice.it wrote:

BC wrote:

...

...

The task of postfix seems to me fairly easy to understand, so I don't see why implementing a solution should be that difficult.

...

It seems easy to understand because you do not understand it. The more you delve into the topic of mail, the more you realize it is not easy to understand with just a few passing glances.

You should read more carefully. I said the _task_ of postfix is fairly easy to understand.

As BC wrote, you think it's easy to understand because you do not understand it. You can choose to believe that or not.

The true educators are those who filter out the essential core.

You could easily do s/educators/students/ and continue to be true.

--keith

On Wed, Aug 13, 2014 at 5:55 PM, Timothy Murphy gayleard@alice.it wrote:

...

As I see it, the principal task of postfix is to take in email arriving at port 25, and convey it to one or more destinations.

In my experience email has been working without problems for as long as Unix has been running, long before system administrator exams were invented.

That was back when it was safe to assume that those one or more destination wanted to receive anything that showed up on port 25. Or that you could reasonably accept the unwanted data and subsequently send it back to wherever the From: line said it came from. Which was basically never but people used to do it before they knew better.

It is not necessary to understand how the internal combustion engine works in order to drive a car; and there is no evidence that those who do know make better drivers.

Not a good analogy. Cars have a fairly useful user interface for the decisions drivers need to make. MTA's need to have helper programs hooked into various places that are much less standardized to make some decisions for you.

On Wed, Aug 13, 2014 at 6:19 PM, Timothy Murphy gayleard@alice.it wrote:

...

That was back when it was safe to assume that those one or more destination wanted to receive anything that showed up on port 25. Or that you could reasonably accept the unwanted data and subsequently send it back to wherever the From: line said it came from. Which was basically never but people used to do it before they knew better.

But it is still reasonably easy to say what you want to do with email, even if it is hard to implement.

No, it is next to impossible to describe what is spam and fairly difficult with viruses. And you have to categorize it before you can do something with it.

My statement was that "the TASK of postfix is fairly easy to understand".

Sure, as long as you don't need to make any choices...

You are clutching at straws.

"Whatever can be said can be said clearly" - Wittgenstein

'Clearly' isn't a problem. 'Concisely' would be a problem for anything that permits more or less arbitrary choices.

On Thu, Aug 14, 2014 at 7:27 PM, Timothy Murphy gayleard@alice.it wrote:

That is not part of the task of postfix, which is what I was discussing. In fact, it is very easy to say what I want to do with viruses and spam. I want email to pass through clamd to catch viruses, and I want email to pass through spamassassin to catch spam. I'm happy to leave the definition of spam to spamassassin, and leave Mr Bayes to do my thinking for me.

And therein lies the problem. Unfortunately spamassassin is not really the best way to stop spam. You need more. Spamassassin should just be a tool in the toolkit not the entire solution. It is CPU and bandwidth intensive. A large proportion of spam can and should be rejected, before the body of the email is received.

On Thu, Aug 14, 2014 at 8:49 PM, Timothy Murphy gayleard@alice.it wrote:

David Beveridge wrote:

...

...

I'm happy to leave the definition of spam to spamassassin, and leave Mr Bayes to do my thinking for me.

And therein lies the problem.

...

Unfortunately spamassassin is not really the best way to stop spam. You need more.

Speak for yourself.

I do

Spamassasin does a pretty good job for me.

Postfix is incredibly configurable and where it's warranted, many filters can be brought to bear. If you don't need them good for you.

...

Spamassassin should just be a tool in the toolkit not the entire

solution.

...

It is CPU and bandwidth intensive.

I get about 300 emails a day on my small system, of which about 150 are spam, as defined by SA. I don't think this is likely to burn out my (ancient) CPU.

Precisely why it is difficult to come up with a one-size fits all solution.

...

A large proportion of spam can and should be rejected, before the body of the email is received.

I'm sure if and when such a system becomes available RedHat and CentOS will implement it, and I shall take advanage of their expertise.

such systems are available. eg policyd-weight As mentioned earlier on this thread.

I assume you are speaking of a system with hundreds or thousands of users. (Do such systems still exist? I thought they had died out.) I have 4 users. Our needs are very different.

Yes, my server handles email for hundreds of uses, and you're right about that, is was thousands. google uses postfix too and I'm sure they're in the millions of users.

Incidentally, I get email from sources who filter out spam, eg my college, and they don't seem to do a much better job than SA. I'm still invited to marry beautiful ladies from Russia.

Why would your college sysadmin be an expert at spam prevention?

Thanks Adam, it works for me now and I have summarized my setup at:

http://serverfault.com/questions/619537/use-postfix-and-spamassassin-package...

I don't see a reason to add a milter or amavis - because my server is idling.

Regards Alex

On Thu, Aug 14, 2014 at 2:23 PM, Adam King kinga@sghs.org.uk wrote:

A message to the original poster.... do you still need help?

On Thu, 2014-08-14 at 01:19 +0200, Timothy Murphy wrote:

Les Mikesell wrote:

...

On Wed, Aug 13, 2014 at 5:55 PM, Timothy Murphy

...

...

In my experience email has been working without problems for as long as Unix has been running, long before system administrator exams were invented.

That was back when it was safe to assume that those one or more destination wanted to receive anything that showed up on port 25. Or that you could reasonably accept the unwanted data and subsequently send it back to wherever the From: line said it came from. Which was basically never but people used to do it before they knew better.

But it is still reasonably easy to say what you want to do with email, even if it is hard to implement. My statement was that "the TASK of postfix is fairly easy to understand".

Yes, but you want to add a turbo to the combustion engine and then the simple user interface is not enough anymore...

Keith Keller wrote:

If you believe that I have been helpful in the past, isn't the simplest explanation that it's possible I'm being helpful now?

No. You were offensive. Nothing you said was of the slightest help.

...

I give you the same answer - if you believe the TASK of postfix is difficult to understand, explain why.

It is difficult to understand because two of postfix's primary tasks are to implement SMTP and deliver mail safely. Both of these tasks are themselves difficult to do well, especially SMTP, a service widely targeted by attackers which offers little in the way of authentication.

Read the question again. more carefully. The TASK of postfix is fairly easy to understand, not the IMPLEMENTATION.

The Prime Number Theorem is easy to state; it is hard to prove.

...

It is not necessary to understand how the internal combustion engine works in order to drive a car; and there is no evidence that those who do know make better drivers.

In this analogy, drivers == email users. If you are running an SMTP server, you're a mechanic, *not* a driver! If you don't want to understand how a car works, you shouldn't be a mechanic.

Every Linux user is a system administrator.

On 13/08/14 17:32, Timothy Murphy wrote:

BC wrote:

...

...

I've never seen a 1-page document that said, "These are the changes I made after downloading packages X, Y and Z."

...

There is a large chasm between configuring a mail server and understanding the configuration of a mail server. Due to the many pitfalls and custom environments, it is very difficult to have a 1-page document that does much more than be an outbound MTA.

Note what I asked for. If you have installed postfix + spamassassin or whatever under CentOS then presumably you downloaded certain packages and then made certain changes in config files and perhaps elsewhere. Therefore it is possible to write a short document just listing the changes you have made. It may be a waste of time in your view; but in my experience this is exactly what I want to read for my very basic home server needs.

Yes, I did exactly that for CentOS 5, and you can find it on the Wiki here:

http://wiki.centos.org/HowTos#head-0facb50d5796bee0bd394636c32ffa9a997a6ab5

There's a basic Postfix/Dovecot guide:

http://wiki.centos.org/HowTos/postfix

It lists all the config changes required in Postfix and Dovecot for a basic Postfix server (assumes networking knowledge).

Then you can add in some simple spam filtering with Postfix restrictions:

http://wiki.centos.org/HowTos/postfix_restrictions

or greylisting:

http://wiki.centos.org/HowTos/postgrey

or bolt on Amavisd/SpamAssassin:

http://wiki.centos.org/HowTos/Amavisd

or bolt on some encryption with SASL and SSL/TLS

http://wiki.centos.org/HowTos/postfix_sasl

These guides were all designed to be fully functional and modular so you could pick just the bits you wanted to extend your basic Postfix installation.

There will be some config differences between el5 and el6 due to the different versions of the packages used. If you can't figure out the differences just go with the docs provided on el5 - it's supported for another 3 years or so.

If you get it working on el6/el7 please feel free to fork the docs for those dists. I know of at least one person running this setup on el6 with the extra packages from EPEL.

This really isn't that difficult. The Postfix docs are excellent. You just need to spend a day reading (and understanding) the docs. The main confusion seems to stem from the fact that there are so many different ways to implement a solution and there is no right or wrong way to do it. But this just illustrates the ultimate flexibility of the software you are using.

The methods documented above illustrate one such approach. I (and another contributor to this list) documented it for the wider community as it's the method we use. If you don't like it feel free to use another approach, but please don't complain that there isn't any documentation when we worked really hard to develop those docs for the community.

If you want an easy to setup postfix instance with a web interface have a look at Zimbra http://www.zimbra.com/community/