Use Postfix And Spamd On CentOS 6 – Looking For A Shortest Guide

Home » CentOS » Use Postfix And Spamd On CentOS 6 – Looking For A Shortest Guide
CentOS 51 Comments

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?

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

Thank you Alex

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

51 thoughts on - 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

  • 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
    http://www.sghs.org.uk

    —– Original Message —

  • Ha what a co-incidence, just did this an hour ago I roughly followed this http://www.rosehosting.com/blog/how-to-install-and-integrate-spamassassin-with-postfix-on-a-CentOS-6-vps/

    my master.cf looks like this

    spamassassin unix – n n – – pipe
    user=nobody argv=/usr/bin/spamc -f -e
    /usr/sbin/sendmail -oi -f ${sender} ${recipient}

    I also have these

    policy_spf unix – n n – 9 spawn
    user=nobody argv=/usr/bin/perl /etc/postfix/policy_spf_d.pl policy_grey unix – n n – 9 spawn
    user=nobody argv=/usr/bin/perl /etc/postfix/policy_greylist_d.pl

    In my case I only want to filter through spamassassin is spf doesn’t pass so I hacked the policy_spf_d

    # else { return “DUNNO”; }
    else { return “FILTER spamassassin:scanner”; }

    Just watch out, if you filter all the mail using content_filter=spamassassin you will create a mail loop unless you use a content filter bypass on mail coming back from spamassassin.

    dave.

  • 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-packages-on-CentOS-6-to-reject-spam-without-custo

    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=, size43, nrcpt=1 (queue active)
    postfix/qmgr[2550]: 831CA809733: from=, sizeA369, nrcpt=1 (queue active)
    postfix/qmgr[2550]: 42B7A80A312: from=, sizeC99, nrcpt=1 (queue active)
    postfix/qmgr[2550]: AED94809D29: from=, size(035, nrcpt=1 (queue active)
    postfix/qmgr[2550]: E69AA809D3C: from=<>, size487, nrcpt=1 (queue active)
    postfix/qmgr[2550]: 2BDE980A61B: from=, size@73, nrcpt=1 (queue active)
    postfix/qmgr[2550]: 0D37280A51F: from=, sizex88, 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=, orig_to=< simplex@simplex.ru>, relay=alt1.gmail-smtp-in.l.google.com[74.125.25.27]:25, delayc25, delaysc23/0/1.2/0.61, dsn=4.7.0, status

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

    [ … ]

    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.html

    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.

    [ … ]

    Alexander

  • 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
    http://www.sghs.org.uk

    —– Original Message —

  • while you haven’t settled on anything you could consider amavisd as well…

    http://www.amavis.org/

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

  • Another alternative to milters is the postfix policy daemons. The best one to use for block and reject is policyd-weight. found here http://www.policyd-weight.org/

    This gives spam a weight based on a number of factors. I setup to do this score <0 accept immediately score <10 greylist then verify sender, then spf, then spamassassin if not spf pass. score >10 reject immediately

    dave

  • Hello again,

    here is my solution on how to use Postfix + Spamassassin on CentOS in 4
    steps:

    1) yum install spamassassin

    2) useradd spam

    3) Add the following line to /etc/postfix/header_checks:

    /^Subject: \[SPAM\]/ DISCARD

    4) Add the following lines to /etc/postfix/master.cf:

    SMTP inet n – n – – SMTPd -o content_filter=spamassassin
    spamassassin unix – n n – – pipe user=spam argv=/usr/bin/spamc -f -e
    /usr/sbin/sendmail -oi -f ${sender} ${recipient}

    More details:

    http://serverfault.com/questions/619537/use-postfix-and-spamassassin-packages-on-CentOS-6-to-reject-spam-without-custo

    Regards Alex

  • Am 12.08.2014 um 00:09 schrieb David Beveridge:

    You should have mentioned that policyd-weight has nothing to do with integrating spamassassin into Postfix. The scores you speak about are not spam scoring points coming from spamassassin.

    Alexander

  • Valeri Galtsev wrote:

    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.

  • 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. One seemingly minor and innocuous change to main.cf can create an open relay or an infinite loop (especially when adding content pipes) or any number of other problems. Unlike apache, you can’t just tweak the config after a failure and hit ‘refresh’. 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. See this comment in the standard httpd.conf:

    # Do NOT simply read the instructions in here without understanding
    # what they do. They’re here only as hints or reminders. If you are unsure
    # consult the online docs. You have been warned.

    I would highly recommend getting a book on postfix. It is very enlightening and well worth it. The problem scope of mail is large and complex and small scattered online docs will not lead you easily to an understanding of that scope.

  • BC wrote:

    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.

    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.

    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.

    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.

  • Try EXIM – it worked for me almost out-of-the-box with very minimal configuration. Since then I have introduced lots of extra refinements to successfully keep spam out without using third party facilities.

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

  • No, I believe education is meritorious.

    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. Perhaps that is why you are not finding a simple document to answer your question.

    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. You rejected it, and that is fine. The only other suggestion I could make is to also read the postfix mailing list (http://www.postfix.org/lists.html)
    or the spamassassin mailing list (
    https://wiki.apache.org/spamassassin/MailingLists). Do with it what you will.

  • 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).

  • Always Learning wrote:

    I should have said, perhaps, that shorewall is working perfectly for me, under both CentOS-6 and CentOS-7. I run amavis under CentOS-6 to incorporate spamassassin and clamav. However, amavisd-new wasn’t available when I installed CentOS-7 –
    I know it is available now – so I went on a strange journey using dovecot-pigeonhole and sieve, which I would not recommend to anyone.

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

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

  • would go back to sendmail. 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
    ++++++++++++++++++++++++++++++++++++++++

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

  • That was true when postfix was initially written, but subsequently, the sendmail has been audited more thoroughly than any other piece of code you are likely to use (certainly more than openssl, which everyone used to trust…) and split into submissioin and delivery processes with milter hooks to let additional processing steps run as different, non-root users. While anything can have undiscovered bugs, at this point I don’t think it is fair to say that one is any more secure than the other.

    But likewise, the rpm-packaged sendmail comes with a configuration that only needs a few tweaks to the readable sendmail.mc file for most common uses. And MimeDefang lets you do anything more complex in perl. I haven’t seen anyone here claim to have hooked MimeDefang to postfix but it should be theoretically possible now that postfix supports milters.

  • 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
    ++++++++++++++++++++++++++++++++++++++++

  • Ahh, the days of wooden computers and iron programmers. Back then, compilers were a rare, extra-cost item that you probably wouldn’t have on your mail server and an embedded macro language was an efficient way to control it. Still works, but once the macro has been written, all you have to do is copy it and the m4 processor provides a way to make customized copies.

  • 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

  • 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.

  • 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.

    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.

  • 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.

  • Maybe, if you refuse to use the milter interface introduced in 2001. Or the available programs that do the work for you.

    There’s not really a requirement for that. And a multi-homed host or one behind nat may not know what IP you think it has.

    I think sendmail can do those natively – or more easily with milters.

    But why would you?

  • BC wrote:

    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?

    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.

    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.

  • The problem is that with anything as complex as mail systems, OS
    distributions, computer languages, etc. no one ever has time to understand more than one or at best a few choices or to keep up with their changes over time. So it is almost impossible to get a good comparison or recommendation for a situation resembling your own – or anything that goes beyond ‘this worked for me once…’.

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

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

    –keith

  • Keith Keller wrote:

    I seem to recall that you have very occasionally made helpful suggestions –
    maybe I am confusing you with someone else.

    I give you the same answer – if you believe the TASK of postfix is difficult to understand, explain why. BC hasn’t answered this, and I very much doubt if KK will either.

    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.

    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.

  • 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.

    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.

  • Les Mikesell wrote:

    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”.

    You are clutching at straws.

    “Whatever can be said can be said clearly” – Wittgenstein

  • 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.

    Sure, as long as you don’t need to make any choices…

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

  • I am somewhat mortified that you are not applying Occam’s razor here. 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? (Whether I
    actually have been helpful is in the eye of the beholder; I like to believe it myself, but that’s pure conceit.)

    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.

    We both did; don’t blame us if you didn’t like the response.

    There are *so* many details that you ignore in this gross oversimplification. The most dangerous one is, what mail do you accept, and what mail are you willing to convey? One mistake in this area and you become a spam relay.

    This is patently untrue. Here’s just one example:

    https://en.wikipedia.org/wiki/Morris_worm

    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.

    –keith

  • I have used these docs a number of times (yes all of them) for CentOS-5
    with no apparent issues – Thanks guys – much appreciated from me.

    I have just (8 months) set up a new CentOS-6 server using the same guides with few changes needed – I have just implemented virtual mail boxes on this for multiple domains, all working but no admin interface –
    i.e. need to edit config files to add users etc. Still looking into this bit to see if there is an option that is not full of security holes, thus far I would not expose the admin interfaces to the internet, i.e. only make them internally accessible. HTH

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

  • Les Mikesell 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.

    Once I have postfix, spamassassin and dovecot working together I don’t want to make any choices in this area. I just want to read my email on laptop or android, and similarly for the few other users on my small system.

    There are enough problems in life without inventing new ones.

  • Keith Keller wrote:

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

    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.

    Every Linux user is a system administrator.

  • 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.

  • David Beveridge wrote:

    Speak for yourself. Spamassasin does a pretty good job for me.

    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.

    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.

    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.

    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.

  • I do

    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.

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

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

    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.

  • Wow! As a system administrator, I object.

    One only becomes knowledgeable in some field when one has enough knowledge to realize how much in this field he does not know.

    Stealing analogy from one of previous posts: you can be good driver, this does not make you a car mechanic. Going further: being great car mechanic doesn’t make one an engineer capable to design new car.

    UNIX user is on the level of driver. Very very very advanced UNIX user approaches system administrator, – with a willingness to waste a lot of time and learn by doing that is. Luckily for me users of boxes I
    administer consider their science more important than fiddling with the system.

    Sorry I break it for you this way, I was a programmer myself long before I
    first put my dirty hands into the kernel code (you see, I’m still skeptical about my editing kernel code). And I was UNIX user (and a user of a bunch of other systems) before becoming UNIX sysadmin. There is the difference, trust me on that, I’ve been there.

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

  • The task of an SMTP service is what? To route messages from origin to destination based on the DNS information relating to the delivery address correct? But SMTP is not intended for message composition, submission, final delivery, display, content checking or any other ancillary operation. And it is these ancillary operations that are the source of much of the complexity and nearly all of the confusion and difficulty experienced with setting up Mail Transfer Agents (MTA).

    For example, a major problem discussed WRT MTAs is the proper setup of SpamAssassin (SA). People talk about setting up SA to filter mail. But SA
    does not do that. It simply scores messages as to the relative likelihood that the message contents are UCE/SPAM. Likewise, ClamAV does not filter for virus infection, it simply detects and reports.

    To filter one must configure the MTA to respond to the reports of SA and ClamAV. And there are many ways of configuring that response. Sendmail uses Milters for example whilst Postfix uses policy daemons. These are fundamentally different approaches to the problem. However, Postfix can also provide a Milter-like interface. Thus the configuration options can get quite extensive and it is difficult to anticipate and describe ‘normal’
    configurations in such a case.

    Using Amavisd-New (http://www.amavis.org/) with Postfix to configure SA and ClamAv to filter mail worked best for me. Trying to get Postfix to work directly with either proved beyond my ability. Even with Sendmail I found that MailScanner was essential to get SA and ClamAV working together. Given that Amavis and MaiScanner exist for the sole purpose of bolting anti-spam and anti-virus filters into Postfix and Sendmail I infer that most people have experiences similar to mine.

    The Postfix mailing list at Cloud9 is a good place to get help WITH SPECIFIC
    POSTFIX PROBLEMS. However, I believe that it would be, shall we say, unwise to ask for hand-held guidance setting up a Postfix MTA on that list. RTFM is perhaps the mildest response one could expect. On the other hand, asking a very specific question about what TFM is trying to say in a particular section usually elicits helpful replies.

    I suggest that you look at Amavisd-New from EPEL and probably ClamAV from the same source (do not mix EPEL and Repoforge packages in this case) and go from there. I believe that you will find that much easier to work with than trying to use SA directly with Postfix.

  • Good stuff, I’ve had a stable environment for around a year now, milter may only bring on a performance increase, nothing else.

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

    —– Original Message —