Re: Planning Mail Server (with low resources)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On Wed, 2005-12-07 at 13:35 -0200, Rodrigo Barbosa wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Wed, Dec 07, 2005 at 03:20:24PM +0000, Karanbir Singh wrote:
> > Rodrigo Barbosa wrote:
> > >>>>IMAP and centralized mail storage is solution for his problem.  And the 
> > >>>>most inexpensive too.  Period.
> > >>>
> > >>>And how do you plan on backuping that ? An array of DLT units ?
> > >>
> > >>Can we stop Trolling here ?
> > >
> > >Who the heck is trolling ? I'm asking a valid question, for a
> > >problem that concerns me. I run several e-mail servers, and the
> > >main problem I have with those is backup.
> > 
> > You forgot to mention all these details in your last email, the one you 
> > replied to with no details of this sort - were a response to the 
> > original posters querry - and the system config there was based on a 40 
> > Gig drive.
> 
> "Mea culpa", then. I did reply without noticing you said it was
> the solution to _his_ problem, and just took it as a general recomendation.
> My bad on that one.
> 
> In any case, one of the things we (I?) noticed on this whole issue
> is that it escalated to much more than the original's poster questions.
> Lots of people suggested he needs more HD space, more e-mail (me included)
> and such.
> 
> At least to me it proves that e-mail servers are giving people more
> headaches than they are supposed to. Of course we all face the
> standard problems regarding spam and virus, but the problems seem to
> be more pervasive than that. I, for one, am surprised. Then again,
> maybe I'm just naive.
> 
> On the other hand, this is first time I see a thread such as this
> where no religious wars started. Usually people will defend their
> MTA of choice, and not even consider the others. Everyone here
> has an MTA of choice, of course, but everyone also pointed to the
> advantages of the other MTAs.
> 
> I think the greater proof that this issue is causing all of us
> headache is that we have diverted a lot from the original topic,
> and still people are not complaining. Which, I hope, shows that
> this whole issue is interesting to at least a number of subscribers.
> I know I am.
> 
> I don't like IMAP. Never did. Maybe this is because of the number of
> bugs we had in the past for all imap implementations. Maybe because
> of the wasted disk space on workstations. I know the backup issue
> is a big problem for me, and users complaining their quota is never
> enough really gets on my nerves. So I try to avoid imap as often
> as I can for everything except webmail.
----
I think that a lot of people's issues are caused by running daemons that
they don't take the time to understand. They get past the initial setup
and then forget about it and when things go awry, they get panicked,
frustrated, desperate.

I can work with sendmail but every time that I wanted to add features, I
felt like I was getting a tooth pulled and postfix seemed more
comprehensible. Learning on Red Hat meant how to survive with wu-imapd
and when I found that future versions of Red Hat (hence CentOS) and
Fedora were using cyrus-imapd, I learned to embrace it and was pleased
that it accommodated my ventures into LDAP as well as gave me the
incredible array of features.

It's not that I couldn't use courier or X-mail or vpopmail or whatever
but the out of band projects aren't logical choices for someone that
doesn't want to commit to maintaining their own upgrades - especially
when considering that the RH packagers have provided reasonable enough
alternatives.

The OP obviously did some research and planning and rather thoughtfully
offered his conclusions for review.

I'm less than certain that the OP was well served by suggestions of out
of band alternatives. Just using one of the daemons supplied in CentOS
and used by a fair cross-section of users on this list provides a
comfort level that most out of band packages could never deliver.

Craig


[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux