>
> Right. I don't see much point in it then for inbound SMTP. Let the DNS and
> MX prefs do the job they were designed to do. IP address space isn't *that*
> expensive.
>
its just that our current situation does not yeild me extra ip space. So I
dont have access to it. Therefore, Im useing an f5 like situation.
> > > 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?
>
> No. I was answering your concern about SMTP having high latency and not
> utilizating your 100Mb (or whatever it was).
>
> I stand by my original comments:
>
> > > 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.
>
> High latency means (relatively) low load per connection and high concurrency rates.
>
> What I'm saying is that your inbound is likely to require more attention
> focussed on you concurrency needs rather than your queue loads.
>
I agree. But given that I may want to have multiple queues, I'm looking
for a pointer on how to handle multiple queues, hopefully with the
benefits and drawbacks the setup.
> It's hard to be more specific without actually seeing your inbound profile.
> If you don't know what the inbound profile will be, then we're all speculating,
> and I'm doing it based on experience.
>
> > > > 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.
>
> Right. You didn't say that. You said "a seperate box". We can only respond
> to the data you give.
>
Im sorry for the confusion. Given boxes that are only for outbound
traffic, are there specific optimizations for qmail servers justy for
outbound traffic?
> > > 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.
>
> Sure. Your choice. I'm just giving you advice based on having done these
> systems and seeing what happens. My advice is that the mailstore is the
> most important and hardest bit to get right. Everything else is easy by
> comparison. Good luck.
>
>
>
> Regards.
>
