On May 28, 2012, at 10:26, David Touzeau wrote: > I have played with DNS and MX but the problem is DNS did not care about > servers load and if servers have a huge queue. > It just balance to next MX only if the server did not respond. > Load-balancing is a cool feature that take care on the server health. > Especially if you add services on the server such as Spamassassin, backup > mails, MDA...
Did you read (and understand) Victor's example? Did you test with multiple servers that had the same preference in their MX record? If they do not have the same preference, the server with the lowest preference value will always be preferred, and failover to the others will indeed only happen when that server is down. -- If you operate at scale, you build out your SMTP infrastructure not just in width, but also in depth; 1) Mail exchangers. Your first 'line of defense'. These show up in your MX records, and run postscreen to fend off bot traffic and the like. They reject everything you know you're not going to accept, BEFORE the queue. How much depends on your profile, but in our case at more than 70% of connections never makes it to the queue. Everything that is accepted is passed on immediately. These do not have any local user mailboxes, and do not do any significant amount of content filtering. They should never have significant amounts of mail in the queue. 2) Mail routing. Where does this message go? Does it need to be archived, copied, rerouted? 3) Content filtering. This is where Spamassassin runs, for example. Spam is marked, everything is passed on. Nothing is bounced, ever. 4) Mailbox server. Accepts the message and sorts them into local folders, where they are stored on disk. This is where POP3/IMAP daemons run to serve users accessing their mailboxes. 5) Submission server. This is what your clients talk to to send their outgoing mail. Requires authentication, runs on port 587, and does not need postscreen. May do some basic checks, but passes messages on as quickly as possible. Should never have much of a queue. 6) Relay servers. These are the servers that talk to the rest of the internet, for outgoing mail. Since you have little control over the availability and load of the servers you are communicating with, mail may be in the queue here for a while, up to several days. -- In most setups, several of these roles can be combined; MX and routing generally go together, and can take care of outgoing relay as well. Content filtering and submission can run on the mailbox servers. But really, find the real bottleneck. You should not need to load balance postscreen, and it's quite likely that it is not the right place to start optimizing. Where are you maxing out? CPU, memory, disk? Is it a single customer that can be split off to a seperate box, perhaps? Cya, Jona -- > Le 27/05/2012 15:25, Wietse Venema a écrit : >> David Touzeau: >>> Dear >>> >>> We are facing an problem that we cannot resolve... >>> Our main goal is to implement a load-balancer in front of Postfix (HaProxy). >>> We have made a discuss with HaProxy founder in order to implement the >>> XCLIENT protcol but this is difficult for him to implement such protocol. >> FYI nginx implements XCLIENT (and more). But it does not matter, >> since postscreen has no proxy support. >> >>> In other way it seems that PostScreen is not really compatible with the >>> proxy protocol. >> First, there needs to be a configuration parameter that tells >> postscreen what kind of proxy command will be prepended to the >> client's SMTP stream. >> >> /etc/postfix/main.cf: >> # Is there a better name than "proxy protocol"? >> postscreen_proxy_protocol = whatever >> >> With this, postscreen will drop connections that fail to conform >> to the configured protocol. >> >> Regardless of command format details, if the proxy prepends a command >> to the client's SMTP stream, then postscreen must use unbuffered >> I/O to read that command. If buffering were turned on, the buffering >> layer could read past the proxy's<CR><LF> and eat up part of the >> client input kind-of like CVE-2011-0411. >> >> A rough estimate of what this requires: >> - A new main.cf parameter and documentation. >> - A way to turn off buffering on VSTREAMs. Alternative: use low-level >> read system calls and re-invent VSTREAM timeout/etc. error handling. >> Either this may take a dozen or so lines of code. >> - A new postscreen code module with generic hook to prepend proxies. >> - An event-driven loop that reads the proxy command one character >> at a time until<CR><LF>, length exceeded, EOF, time limit, or >> other error. Another dozen lines. >> - A proxy command parser that does all the necessary sanity checks >> (valid address syntax, numerical TCP ports in the range 1..65535), >> no missing or extra fields. Another dozen lines. >> - Reuse the existing postscreen data structures that are now filled >> with endpoint information from getpeername() and getsockname(). >> >> Wietse >> >>
