> Is the front end SMTP server doing anything more than relaying? If it's only
> relaying then take it out of the picture. It's only adding a point of failure
> for you.
no, the front end is not smtp relaying.... its like an f5 box, essentially
port forwarding to one of many internal ip addresses.
> As long as you are accepting connections for every MTA that wants to connect
> at any given time, then there is nothing more you can do.
Are you saying that it is a complete waste to have multiple queues running
on the same box, as the load on those boxes rises?
>
> Have all your real SMTP servers accept connections and make sure they have
> enough qmail-smtpd concurrency (via tcpserver, which can be trivially monitored),
> and that's it.
>
> > If I have a seperate box for outbound messages, what are best
> > optimizations?
>
> One box? I'd tend to give my outbound more redundancy than inbound. If no one
> can send email because this box is down, the complainst will come thick and
> fast. If inbound is down for a little while, no one tends to knows.
>
Not one seperate box, but a "model" multiple box that I can replicate.
> It's not the media that's important, it's redundancy I'm talking about.
The redundancy would be taken care of at the hardware level... I'm not
going to worry about the disc side of things just yet. Ill get to that
later, assuming I build a robust enough system that can handle
compatibilty to emc/netapps/whatever i choose.
>
> What if the fibre channel breaks? What if the Netapps fails, what if
> the disks fail? What if the scsi cable melts?
these are issues of fail safe-ness on disc. Im not so concerned with that
now as i am in handeling the traffic in a scaleable manner. the route to
storage can change.
jeff...
