how to setup postfix or qmail to go through a email proxy


I am looking to setup a email proxy server. The "scheme" I am using is;

Internet  >> ASSP(proxy) >> Email Server

Email Server >>>> ASSP(proxy) >>> Internet

I am wanting to use ASSP (

ASSP and the Email server are on different severs so the port's shouldn't have an issue. What I am needing to know if possible is how to setup the email server to talk through the proxy server? What I have gather is with a "smarthost". Can you give me a step by step guide on this? If you are needing anything let me know.

Thank You,
Who is Participating?
Daniel McAllisterConnect With a Mentor President, IT4SOHO, LLCCommented:
Hehe... QMail could reasonably be setup to act as EITHER role (or, two QMail servers could EACH be one of them)... the email server OR the ASSP proxy! Unfortunately, you haven't made it clear which (or both) will be using QMail...

In any case, all you really need to fool with are the files:
Plus, the MX server records in your DNS.

Since you want step-by-step instructions, I'm going to ASSUME that separate QMail servers are filling EACH role:
 - The "local" e-mail server is at (or WAN IP address, and LAN IP
 - the ASSP server is at (or WAN IP address
 - The domain you're serving (could be one of many) is
 - Optionally (to make things easier later): points to the ASSP server ( (and, if need be points to the "real" mail server (

So - here are the configuration items to note:
 1 - The MX records for should point exclusively to the ASSP server:, or specifically
 2 - The ASSP server (running QMail) will list the domain(s) being filtered in the /var/qmail/control/rcpthosts file
      The rcpthosts file is just a list of domains you accept mail for that aren't going to be processed locally
      So, entering your domain(s) here means you'll accept mail for those domain(s), even though they're not local
      The format of the rcpthosts file is simply a list of domain names, one per line... that's it!
 3 - The ASSP server (running QMail) also needs to identify the REAL mail server to deliver the filtered mail to:
      The operative file is /var/qmail/control/smtproutes
      The smtproutes file tells your system where to deliver mail for domains that are NOT controlled by DNS MX records
      The format is of the general form:
          domain:server[:port] [username] [password]
      So, in it's simplest form let's assume:
        - the Real Mail Server is
        - there are no "rules" on that server about accepting mail from the ASSP server
        - the Real Mail Server accepts connections on port 25 ONLY from the ASSP server
          (either in a firewall setting, or in a tcp.rules setting)
        - No authentication or different port or SSL setting is required (not a problem is the above rule is in place)
      ... then the smtproutes entry (line) would look like:

So, that takes care of getting mail INBOUND through your ASSP server.... what about the other 2 cases? (outbound messages and internal messages)

 4 - The EASIEST thing to do is to let the ASSP server act as the MX server for your "real" domain -- even for internal users (that is, tell your users to use the IMAP server at and the SMTP server at

To "do this RIGHT", you'd also have them use IMAPS and SMTPS -- furthermore, you'd make SMTPS connect on port 465 (to keep it separate from the inbound "filtered" email).... and the use of IMAPS and SMTPS takes you to the use of SSL certificates, which if unsigned, causes a "certificate warning" message until you force the client systems to accept the unsigned certificate. The cost to "sign" a certificate varies WILDLY -- from about $10/year to about $80/year!)

BUT -- if for some reason you REALLY want users to send their messages through, then you'll need to force it (localmail) to send all of it's outbound mail through the ASSP (aka: smarthost). Fortunately, this is exceptionally simple... just use a "wildcard" in your smtproutes file.... something like

That is, put NOTHING in front of the first colon in the smtproutes file, and it assumes you mean ALL mail.

That's about it... if YOUR QMail server is only playing one role or the other, just skip the steps for the server that's NOT QMail...

For example, if you're using Verizon's smarthost, and they want you to send outbound mail on port 26, you'd just make the smtprouts entry look like:

And if they wanted you to LOGIN to the smarthost on port 26 with a username of with a password of "password1234", the line would look like: "" "password1234"

That should about cover it... reply with questions!!!

on the qmail side: you would add the entry in /var/qmail/control/smtproutes
:<replace_all_this_with_the_assp_proxy_ip>[:port] #(if the ASSP proxy is not listening on port 25.

In postfix, in /etc/postfix/ define the

You may need to alter the port (SMTP) in the postfix example above if assp proxy is not listening on port 25.
tdog89Author Commented:
The actual proxy will have nothing. I am looking at either setting up postfix or qmail. Only 1 email server and 1 proxy server both being on 2 separate servers
There are ways to configure both qmail and postfix to handle/process the incoming message to check that it is not spam. using spamassin, etc.
You could use qmtp to transfer messages from the proxy to the local delivery qmail setup which will significantly speed things up as compared to having the proxy transmit a message at a time.

Daniel McAllisterPresident, IT4SOHO, LLCCommented:
Since you appear to be implementing BOTH servers, I think it is reasonable to ask WHY two servers?

As has been mentioned, both PostFix and QMail (heck, even Sendmail) can reasonably block most SPAM without the use of another server. The use of an ASSP (SPAM blocker Proxy) is USUALLY done by a "Service Provider" who wants to offer the services of their SPAM blocking technology (and subscriptions to additional SPAM blocking tools) to their own subscribers as a for-profit exercise. ASSP providers usually have a STAFF of E-Mail EXPERTS available on-call 24/7 -- after all, if the ASSP server goes down, all of its client systems E-Mail servers will be down too!

My point is this: If you're implementing your own Mail service for the first time, you should probably SUBSCRIBE to an ASSP service, while at the same time learn how to do most of the SPAM blocking on your own server. When you're comfortable implementing SPAM blocking tools on your own server, you can remove the ASSP system (and the expense)... but to implement an in-house PAIR of servers -- one an ASSP and the other a standard E-Mail Server is a waste of time and resources. For a single set of domains (serviced by a single E-Mail server), the functions of the ASSP could be far (FAR) more easily integrated directly into the E-Mail server itself.

Just my thoughts... they can't be worth LESS than what you paid for them! :-)

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.