An interesting point came up while recently discussing my Postfix virtual_alias issues with the MailScanner list. Apparently there is some risk with the "two instances of postfix" approach described in: http://www.hughesjr.com/content/view/12/30/Guides
It sounds like Postfix and MailScanner can step on each other in the deferred queue. They recommended the single Postfix instance "hold" mechanism recommended here: http://www.sng.ecs.soton.ac.uk/mailscanner/install/postfix.shtml
Here are the steps I used to convert:
1) service MailScanner stop
2) Edit MailScanner.conf and change Incoming Queue Dir = /var/spool/postfix.in/deferred to Incoming Queue Dir = /var/spool/postfix/hold
3) Rename /etc/postfix.in to /etc/postfix.old-in
4) Rename /var/spool/postfix.in to /var/spool/postifx.old-in
5) Edit /etc/postfix/master.cf and uncomment the "smtp inet n - n - - smtpd" that was commented out in Step #12 of the 2-step instructions
6) Edit /etc/postfix/main.cf and add: header_checks = regexp:/etc/postfix/header_checks
7) Create /etc/postfix/header_checks containing: /^Received:/ HOLD
8) service MailScanner start
And you should be back in business. Note that the /etc/init.d/MailScanner script still references both an in and out Postfix instance; however, in looking at the code, once /etc/postfix.in is gone/renamed the "in" startup action becomes a no-op.
I should also point out that there is absolutely NO implied criticism of the SUPERB guides Johnny has put out. I have found them to be extremely helpful -- thanks, Johnny!
Regards, Kennedy
On Sat, 2005-04-09 at 17:32 -0400, Kennedy Clark wrote:
An interesting point came up while recently discussing my Postfix virtual_alias issues with the MailScanner list. Apparently there is some risk with the "two instances of postfix" approach described in: http://www.hughesjr.com/content/view/12/30/Guides
It sounds like Postfix and MailScanner can step on each other in the deferred queue. They recommended the single Postfix instance "hold" mechanism recommended here: http://www.sng.ecs.soton.ac.uk/mailscanner/install/postfix.shtml
Here are the steps I used to convert:
service MailScanner stop
Edit MailScanner.conf and change Incoming Queue Dir = /var/spool/postfix.in/deferred
to Incoming Queue Dir = /var/spool/postfix/hold
Rename /etc/postfix.in to /etc/postfix.old-in
Rename /var/spool/postfix.in to /var/spool/postifx.old-in
Edit /etc/postfix/master.cf and uncomment the "smtp inet n - n - -
smtpd" that was commented out in Step #12 of the 2-step instructions
Edit /etc/postfix/main.cf and add: header_checks = regexp:/etc/postfix/header_checks
Create /etc/postfix/header_checks containing: /^Received:/ HOLD
service MailScanner start
And you should be back in business. Note that the /etc/init.d/MailScanner script still references both an in and out Postfix instance; however, in looking at the code, once /etc/postfix.in is gone/renamed the "in" startup action becomes a no-op.
I should also point out that there is absolutely NO implied criticism of the SUPERB guides Johnny has put out. I have found them to be extremely helpful -- thanks, Johnny!
No offense taken ... :)
The new method is a bit easier, and I am working now on a guide for CentOS-4 that does it the new way and uses cyrus-imapd.
I have used the other way (two postfixes) on several high volume servers, and have personally had no problems. Other people have said they sometimes have issues with the two postfix setup.
As soon as we finish CentOS-4.1 (or maybe before, depending on how long RH takes to go from the beta update1 to it's release), I should be able to change my CentOS-3.x guide to the single postfix instance mode and get a CentOS-4 postfix guide out the door.
On Apr 9, 2005 7:34 PM, Johnny Hughes mailing-lists@hughesjr.com wrote:
I should also point out that there is absolutely NO implied criticism of the SUPERB guides Johnny has put out. I have found them to be extremely helpful -- thanks, Johnny!
No offense taken ... :)
Good. I was a little worried about that. :-)
The new method is a bit easier, and I am working now on a guide for CentOS-4 that does it the new way and uses cyrus-imapd.
I have used the other way (two postfixes) on several high volume servers, and have personally had no problems. Other people have said they sometimes have issues with the two postfix setup.
On a related point: I have been reading over in the postfix user list archives how they are *really* down on mixing MailScanner and Postfix. They say fairly serious queue, email and filesystem corruption is a certainty. Yikes. I'm stressing out now that I just invested a ton of time coming up to speed on MailScanner over the past 10 days. :-\ Anyone have advice for me? Is it really that bad? Does the one instance of Postfix help (or better yet *fix*) this issue? Do recent versions make things any better/worse here?
They seem to like amavisd-new.
As soon as we finish CentOS-4.1 (or maybe before, depending on how long RH takes to go from the beta update1 to it's release), I should be able to change my CentOS-3.x guide to the single postfix instance mode and get a CentOS-4 postfix guide out the door.
Glad to help if I can.
Regards, Kennedy
On Sat, 2005-04-09 at 20:35 -0400, Kennedy Clark wrote:
On Apr 9, 2005 7:34 PM, Johnny Hughes mailing-lists@hughesjr.com wrote:
On a related point: I have been reading over in the postfix user list archives how they are *really* down on mixing MailScanner and Postfix. They say fairly serious queue, email and filesystem corruption is a certainty. Yikes. I'm stressing out now that I just invested a ton of time coming up to speed on MailScanner over the past 10 days. :-\ Anyone have advice for me? Is it really that bad? Does the one instance of Postfix help (or better yet *fix*) this issue? Do recent versions make things any better/worse here?
They seem to like amavisd-new.
Everyone has their own agenda (and favorite software) ... I have never had a problem with MailScanner. I am using it in several places. I know z00dax also uses MailScanner ... I have used amavisd-new, it works fine too.
The postfix guys also say compile your own and don't use the distro version. I say, also use RPMs so you can continue to get security updates.
On Apr 10, 2005, at 6:50, Johnny Hughes wrote:
The postfix guys also say compile your own and don't use the distro version. I say, also use RPMs so you can continue to get security updates.
Even though this topic of prepackaged-vs-RPM is a total rat-hole I'd like to note that the "anti-prepackaged" attitude most likely stems from the fact that most distros ship either ancient versions or versions that simply don't have a lot of desired extensions (or "usable versions" of these extensions) linked in.
For me the postfix that shipped with Centos4 was the first RPM that I successfully used in a setup where LDAP and SASL play important roles, everywhere else I had to roll my own.
jens
On Sun, 2005-04-10 at 12:32 +0200, Jens Vagelpohl wrote:
On Apr 10, 2005, at 6:50, Johnny Hughes wrote:
The postfix guys also say compile your own and don't use the distro version. I say, also use RPMs so you can continue to get security updates.
Even though this topic of prepackaged-vs-RPM is a total rat-hole I'd like to note that the "anti-prepackaged" attitude most likely stems from the fact that most distros ship either ancient versions or versions that simply don't have a lot of desired extensions (or "usable versions" of these extensions) linked in.
This is true if you want functionality that is not included in the software provided by the distro {either because the included version is an older version or the distro in question decided that you didn't need that :)}. I try to stay within the functionality of the distro I have choose, if possible ... sometimes it is not. ------------------------------------------ {not to Jens particular, but to everyone :)} If you are going to compile a program from source (or roll your own SRPMS/RPMS for it), remember that you will have to keep your own software up2date ... and weigh the benefits of the new features against your own skills to keep your software updated :)
Having outdated software installed can lead to you being owned :)
Johnny Hughes wrote:
On Sun, 2005-04-10 at 12:32 +0200, Jens Vagelpohl wrote:
On Apr 10, 2005, at 6:50, Johnny Hughes wrote:
The postfix guys also say compile your own and don't use the distro version. I say, also use RPMs so you can continue to get security updates.
Even though this topic of prepackaged-vs-RPM is a total rat-hole I'd like to note that the "anti-prepackaged" attitude most likely stems from the fact that most distros ship either ancient versions or versions that simply don't have a lot of desired extensions (or "usable versions" of these extensions) linked in.
This is true if you want functionality that is not included in the software provided by the distro {either because the included version is an older version or the distro in question decided that you didn't need that :)}. I try to stay within the functionality of the distro I have choose, if possible ... sometimes it is not.
{not to Jens particular, but to everyone :)} If you are going to compile a program from source (or roll your own SRPMS/RPMS for it), remember that you will have to keep your own software up2date ... and weigh the benefits of the new features against your own skills to keep your software updated :)
Having outdated software installed can lead to you being owned :)
I'd love to use pre compiled Postfix, but unfortunately I use it with Mysql/Courier-IMAP/SASL and I've yet to see a Postfix rpm that can handle that. I also use Amavis-new/spamassassin/Clamd for a nice fast virus/spam solution.
The closest I've ever gotten to an out of the box install of all that was using Mandrake believe it or not. They had contrib rpms for everything needed for clamd/amavis-new/spamassassin but still fell short on the mysql/courier/sasl side. (that that that wasn't expected) my current mail server is a Debian Woody box with lots of updated packages and a self compiled Postfix.
rgds
Franki
Franki wrote:
I'd love to use pre compiled Postfix, but unfortunately I use it with Mysql/Courier-IMAP/SASL and I've yet to see a Postfix rpm that can handle that. I also use Amavis-new/spamassassin/Clamd for a nice fast virus/spam solution.
The closest I've ever gotten to an out of the box install of all that was using Mandrake believe it or not. They had contrib rpms for everything needed for clamd/amavis-new/spamassassin but still fell short on the mysql/courier/sasl side. (that that that wasn't expected) my current mail server is a Debian Woody box with lots of updated packages and a self compiled Postfix.
I'm a bit curious what benefit you achieve from adding the complexity of mysql into the mix. Does it improve performance? Is there some feature that you need that is only available if you hook in a database back-end?
Also, how many users does this server provide mail service for?
Best regards,
Chris
Chris Mauritz wrote:
I'm a bit curious what benefit you achieve from adding the complexity of mysql into the mix. Does it improve performance? Is there some feature that you need that is only available if you hook in a database back-end?
Probably so it's easier to administer user accounts using a web interface or any other type of UI. I doubt it's primarily for performance reasons. Personally, I prefer an LDAP backend for that purpose.
On Apr 10, 2005, at 19:16, Avtar Gill wrote:
Chris Mauritz wrote:
I'm a bit curious what benefit you achieve from adding the complexity of mysql into the mix. Does it improve performance? Is there some feature that you need that is only available if you hook in a database back-end?
Probably so it's easier to administer user accounts using a web interface or any other type of UI. I doubt it's primarily for performance reasons. Personally, I prefer an LDAP backend for that purpose.
I've done what Franki described with a LDAP backend, because LDAP rocks in these massive read situations. The Postfix in Centos/RHEL 4 was the first that had usable versions of Postfix, OpenLDAP and SASL to make it all work without compiling anything myself.
jens
Jens Vagelpohl wrote:
On Apr 10, 2005, at 19:16, Avtar Gill wrote:
Chris Mauritz wrote:
I'm a bit curious what benefit you achieve from adding the complexity of mysql into the mix. Does it improve performance? Is there some feature that you need that is only available if you hook in a database back-end?
Probably so it's easier to administer user accounts using a web interface or any other type of UI. I doubt it's primarily for performance reasons. Personally, I prefer an LDAP backend for that purpose.
I've done what Franki described with a LDAP backend, because LDAP rocks in these massive read situations. The Postfix in Centos/RHEL 4 was the first that had usable versions of Postfix, OpenLDAP and SASL to make it all work without compiling anything myself.
jens
Now that is interesting. I can see what my next mail server will be running.
I was not happy to have to compile it all myself, for the reasons mentioned. Plus I've always been happier with rpm based systems, not that there is anything wrong with apt, but I started using linux back in early RH 4 days and redhat is what I got to know.
How does redhats rpm tools compare to mandrakes urpm* tools?
On Apr 11, 2005, at 8:16, Franki wrote:
Now that is interesting. I can see what my next mail server will be running.
I was not happy to have to compile it all myself, for the reasons mentioned. Plus I've always been happier with rpm based systems, not that there is anything wrong with apt, but I started using linux back in early RH 4 days and redhat is what I got to know.
How does redhats rpm tools compare to mandrakes urpm* tools?
I'm in the same boat - "grew up" on RedHat so I want to stick with the same environment.
The only RPM tool I use is yum, which I've been using for a couple years now. It's all I need.
jens
Chris Mauritz wrote:
Franki wrote:
I'd love to use pre compiled Postfix, but unfortunately I use it with Mysql/Courier-IMAP/SASL and I've yet to see a Postfix rpm that can handle that. I also use Amavis-new/spamassassin/Clamd for a nice fast virus/spam solution.
The closest I've ever gotten to an out of the box install of all that was using Mandrake believe it or not. They had contrib rpms for everything needed for clamd/amavis-new/spamassassin but still fell short on the mysql/courier/sasl side. (that that that wasn't expected) my current mail server is a Debian Woody box with lots of updated packages and a self compiled Postfix.
I'm a bit curious what benefit you achieve from adding the complexity of mysql into the mix. Does it improve performance? Is there some feature that you need that is only available if you hook in a database back-end?
Also, how many users does this server provide mail service for?
Best regards,
Chris
The main reason was that I wanted all virtual users, no user accounts on the mail server, it hosts many virtual domains and I starting having username/domain conflicts on the old server. (and people were getting annoyed at the really long gibberish passwords I was giving them) With virtual users, they only thing having a shitty password can cost us is the users mail (and they've been warned about that possibility) There is also a plugin for virtual domains and squrillel mail so they can send/recieve as their own user/domain.
The second reason was that they always want to add/remove/redirect user accounts all over the place and by using Postfix Admin (a php application for manipulating the Postfix/mysql db) I can do in seconds what used to take me ages. Seriously this has made me so much more efficient. By the time a client has finished telling me what they want over the phone, I've done it.
The server only handles about 20,000 or so messages a day at present, but growing regularly, it has been a god send from an admin perspective (and security if you consider they are all virtual users only). I'm now looking at powerDNS so I can do the same for the replacement of my Bind server. Then maybe the db backend mods for apache/virtual users..
Anything that makes the task of adding/removing/editing users faster has to be a good thing right? The admin side of the mail server is not accessable to the Internet, only via my laptops IP on the Internal network. I've not noticed any slowdown on the mail server, but this one has allot more horsepower then the old one so that was kinda expected.
rgds
Franki
Franki wrote:
I'd love to use pre compiled Postfix, but unfortunately I use it with Mysql/Courier-IMAP/SASL and I've yet to see a Postfix rpm that can handle that.
Have you seen Simon Mudd's packages? I take the .src.rpm file, modify a few settings and rebuild it with all the Postfix goodies that make my mail server work (MySQL, SASL, etc...)
--Ajay
Ajay Sharma wrote:
Franki wrote:
I'd love to use pre compiled Postfix, but unfortunately I use it with Mysql/Courier-IMAP/SASL and I've yet to see a Postfix rpm that can handle that.
Have you seen Simon Mudd's packages? I take the .src.rpm file, modify a few settings and rebuild it with all the Postfix goodies that make my mail server work (MySQL, SASL, etc...)
I have now.. but I just went though the whole woody install and I have no desire to change that for about another year. It works, it has been flawless and I'm happy with it for now.. but the next version will be CentOS based I think, I'd like to standardize on distro's across the board.. the DNS is the next server to get an upgrade to CentOS.
I've just caught the back end of this thread having spent a few days out of the office and also doing exactly what the OP was doing - moving a mail server (or three!) to a 'one instance' setup of Postfix with MailScanner - I wish I'd seen the messages beforehand as it would have saved me some time - I spent a short while scratching my head wondering why incoming mail was now disappearing before realising it wasn't even being fetched - it's a good idea to re-enable postfix's SMTP servicing!!
I just dropped in to add that with the latest version of MailScanner (4.40.11) I was getting a warning in maillog that unrar wasn't installed and so rar-compressed archives obviously weren't being checked - fortunately, 'yum install unrar' picked it up from Dag's repository so here's a note for Johnny to add it to the Step 1, (Option 1) yum install command in the section about installing Spamassassin and ClamAV and to put a note about installing it if you're not using Dag.
On Apr 10, 2005, at 18:52, Johnny Hughes wrote:
{not to Jens particular, but to everyone :)} If you are going to compile a program from source (or roll your own SRPMS/RPMS for it), remember that you will have to keep your own software up2date ... and weigh the benefits of the new features against your own skills to keep your software updated :)
Having outdated software installed can lead to you being owned :)
You're 100% right, but in a lot of cases there's simply no way around it. Some distributions ship complete garbage, for example the methusaleh OpenLDAP packages that were used in RH-based distributions up to RH9, which they had dragged by its hair all the way from the RH 7.x versions...
jens
-
Ajay Sharma -
Avtar Gill -
Chris Mauritz -
Franki -
Jens Vagelpohl -
Johnny Hughes -
Kennedy Clark -
Nigel Kendrick