Re: [Dovecot] SSD drives are really fast running Dovecot

[Stan Hoeppner]

Rick Romero put forth on 1/15/2011 10:34 AM:

> Also, if your filesystem is using 4k clusters, aren't you only using 1
> random IOPS for a 4k email?   It just sounds to me like if you plan
> 'smarter', anyone can avoid the excessive costs of SSD and get 'end user
> similar' performance with commodity hardware.

This depends heavily on which filesystem you use and the flow of mails/sec.  For
instance, if multiple writes of small (<4KB) files (maildir), or multiple writes
to a single file (mbox) on an XFS filesystem are pending simultaneously, because
XFS uses a delayed allocation scheme, a variable extent size, and because it is
optimized for parallel workloads, it can pack many small files into a single 4KB
extent (if they add up to 4KB or less) and write them to disk in a single IOP.
Likewise, with mbox storage XFS can coalesce multiple writes to the same file
extent in a single IOP.  Moreover, XFS can take a pending write of say, 37 small
files or write fragments to the same file, and if they fit within say, 12KB, it
can write all 37 in 3 pipelined IOPS.  Using O_DIRECT with mbox files, the IOPS
performance can be even greater.  However, I don't know if this applies to
Dovecot because AFAIK MMAP doesn't work well with O_DIRECT...

***Hay Timo, does/can Dovecot use Linux O_DIRECT for writing the mail files?

Now, here's where load issue comes in.  If the pending writes are more than a
few seconds apart, you lose this XFS coalesced write advantage.  I don't know
how other filesystems handle writing multiple small files <4KB.

-- 
Stan

Re: [Dovecot] SSD drives are really fast running Dovecot

[Noel Butler]

LOL this is just s funny., watching the no no no im right you're
wrong, give up stanley, those on many lists are aware of your trolling,
nobody cares about your lil SOHO world, this list contains many
different sized orgs, and like someone else mentione,d the 4K email size
is SO 1994, but, that about sums you up anyway.



On Sat, 2011-01-15 at 23:19 -0600, Stan Hoeppner wrote:

> Philipp Haselwarter put forth on 1/15/2011 8:32 PM:
> 
> > ,
> > | More than 97% of all e-mails sent over the net are unwanted, according
> > | to a Microsoft security report.[39]
> > | 
> > | MAAWG estimates that 85% of incoming mail is "abusive email", as of the
> > | second half of 2007. The sample size for the MAAWG's study was over 100
> > | million mailboxes.[40][41][42]
> > | 
> > | Spamhaus estimates that 90% of incoming e-mail traffic is spam in North
> > | America, Europe or Australasia.[43] By June 2008 96.5% of e-mail
> > | received by businesses was spam.[18][unreliable source?]
> > `
> 
> > I just have a tiny set of 4k spam mails, but they have an avg size of
> > 39KB, ie well above 4KB.
> 
> This discussion has been in the context of _storing_ user email.  The 
> assumption
> is that an OP is smart/talented enough to get his spam filters/appliances
> killing 99% before it reaches intermediate storage or mailboxes.  Thus, in the
> context of this discussion, the average size of a spam message is irrelevant,
> because we're talking about what goes into the mail store.
> 
> If you're storing significantly more than 1% of spam you need to get that 
> under
> control before doing any kind of meaningful analysis of mail storage needs.
> 




signature.asc
Description: This is a digitally signed message part

Re: [Dovecot] SSD drives are really fast running Dovecot

[Stan Hoeppner]

Philipp Haselwarter put forth on 1/15/2011 8:32 PM:

> ,
> | More than 97% of all e-mails sent over the net are unwanted, according
> | to a Microsoft security report.[39]
> | 
> | MAAWG estimates that 85% of incoming mail is "abusive email", as of the
> | second half of 2007. The sample size for the MAAWG's study was over 100
> | million mailboxes.[40][41][42]
> | 
> | Spamhaus estimates that 90% of incoming e-mail traffic is spam in North
> | America, Europe or Australasia.[43] By June 2008 96.5% of e-mail
> | received by businesses was spam.[18][unreliable source?]
> `

> I just have a tiny set of 4k spam mails, but they have an avg size of
> 39KB, ie well above 4KB.

This discussion has been in the context of _storing_ user email.  The assumption
is that an OP is smart/talented enough to get his spam filters/appliances
killing 99% before it reaches intermediate storage or mailboxes.  Thus, in the
context of this discussion, the average size of a spam message is irrelevant,
because we're talking about what goes into the mail store.

If you're storing significantly more than 1% of spam you need to get that under
control before doing any kind of meaningful analysis of mail storage needs.

-- 
Stan

Re: [Dovecot] SSD drives are really fast running Dovecot

[Stan Hoeppner]

Stan Hoeppner put forth on 1/15/2011 11:03 PM:
> Sven Hartge put forth on 1/15/2011 9:29 AM:

>> Mails the average size of 4KiB would then have been at a time when
>> MIME was not yet invented, I believe. Somewhere in 1994.
> 
> No.  You're doing a statistical mean.  You need to be doing median.  The 
> reason
> should be obvious.

Correcting myself here.  You are right, this should be a mean calculation.  And
the reason is obvious. ;)

-- 
Stan

Re: [Dovecot] SSD drives are really fast running Dovecot

[Stan Hoeppner]

Sven Hartge put forth on 1/15/2011 9:29 AM:
> Andrzej Adam Filip  wrote:
>> Stan Hoeppner  wrote:
> 
>>> [...] The average size of an email worldwide today is less than 4KB,
>>> less than one typical filesystem block. [...]
> 
>> Do not confuse "unix culture" of mostly plain text only email messages
>> with "MS Junk" culture of overblown formatting with background images
>> company logos as a few image files in every (internal) email.
> 
> I just did a rough analysis of the mail spool of my university (6.000
> users, students and faculty staff, about 10 million mails) and the
> average mail size was at about 96KiB. Last year, this average was at
> 77KiB and in 2009 we were at 62KiB.
> 
> Mails the average size of 4KiB would then have been at a time when
> MIME was not yet invented, I believe. Somewhere in 1994.

No.  You're doing a statistical mean.  You need to be doing median.  The reason
should be obvious.

-- 
Stan

Re: [Dovecot] v2.0.9 released

[Daniel L. Miller]

On 1/13/2011 3:21 AM, Timo Sirainen wrote:

http://dovecot.org/releases/2.0/dovecot-2.0.9.tar.gz
http://dovecot.org/releases/2.0/dovecot-2.0.9.tar.gz.sig

I'm still lagging behind in my email, but I guess it's time to release
v2.0.9 anyway.


Yeah!

Now just waiting for Pigeonhole to catch up...

--
Daniel

Re: [Dovecot] SSD drives are really fast running Dovecot

[Stan Hoeppner]

Brandon Davidson put forth on 1/14/2011 10:59 PM:

> You obviously don't live in the same world I do. Have you ever been part of

Not currently, no, thankfully.

> a grant approval process and seen what kinds of files are exchanged, and

I've never worked in the public sector, only private, so I've not dealt with the
grant process, but I'm not totally ignorant of them either.  I've assisted a
couple of colleagues in the past with grant proposals.  And yes, they can, and
often do, suck.

> with what frequency? Complied with retention and archival policies? Dealt
> with folks who won't (or can't) delete an message once they've received it?

I have, unfortunately, had to deal with regulatory compliance and some of the
less than sane communications retention policies.

> Blithely applying some inexplicable figure you've pulled out of
> who-knows-where and extrapolating from that hardly constitutes prudent
> planning. 

Statistics are guidelines.  As I'm not planning anything in this thread, I don't
see how such non existent planning could be categorized as prudent or not.  What
I did do is simply make the case that 252TB seems bleeping outrageously high for
5k users, whether that entails email alone or every other kind of storage those
5k users need.  If my math is correct, that's about 50GB/user, including your
snapshot LUNs, etc.

> We based our requirement on real numbers observed in our
> environment, expected growth, and our budget cycle. 

You forgot to mention the 35-45% (mentioned below) gross storage loss due to
inefficiencies in your chosen hardware vendor's platform/architecture.  Over a
third and almost half of the drive cost is entangled here is it not?

> How do you plan? More
> blind averaging?

Ouija board.

> You're close, if a bit high with one of your guesses. Netapp is good to
> Education. 

Vendors with the largest profit margins (read: over priced) built into their
products are those most willing and able to give big discounts to select 
customers.

> Not that it matters - you know very little about the financial
> state of my institution or how capital expenditures work within my
> department's funding model.

That's true.  I know nothing about the financial state of your institution.  I
didn't claim to.  I simply know Oregon was/is facing a $3.8B deficit.  Your
institution is part of the state government budget.  Thus, your institution's
spending is part of that budget/deficit.  That's simply fact.  No?

> I suppose I shouldn't be surprised though, you seem to be very skilled at
> taking a little bit of information and making a convincing-sounding argument
> about it... regardless of how much you actually know.

I know this:  252TB is bleeping ridiculously large for 5K seats at _any_
university, public or private, regardless of how much is wasted for "data
management".  Also, 34%-45% consumption of raw for any internal array
functions/management is bleeping ridiculous.  Is that your definition of
"enterprise"?  Massive required waste of raw capacity?

> I work for central IS, so this is the first stage of a consolidated service
> offering that we anticipate may encompass all of our staff and faculty. We
> bought what we could with what we had, anticipating that usage will grow
> over time as individual units migrate off their existing infrastructure.
> Again, you're guessing and casting aspersions.

Guessing?  Originally you stated that 252TB for email only, or specifically
Exchange.  You said nothing of a mass storage consolidation project:

Brad Davidson put forth on 1/14/2011 6:25 PM:

> We just bought 252TB of raw disk for about 5k users. Given, this is
> going in to Exchange on Netapp


Casting aspersions?  aspersion:

a : a false or misleading charge meant to harm someone's reputation 

What false or misleading charge did I make with the intention to harm your
reputation Brad?  I've merely made a technical argument for sane email retention
policies, and against the need for 252TB for 5K users' email.  I don't recall
casting any aspersions.

> This is enterprise storage; I'm not sure that you know what this actually
> means either.  With Netapp you generally lose on the order of 35-45% due to
> right-sizing, RAID, spares, and aggregate/volume/snapshot reserves. What's
> left will be carved up into LUNs and presented to the hosts.

If your definition of "enterprise storage" is losing 34-45% of raw capacity for
housekeeping chores, then I'll stick with my definition, and with Nexsan for my
"enterprise" storage needs.

You didn't mention deduplication once yet.  With Nexsan's DeDupe SG I cut my
regulatory dictated on disk storage requirements in half, and Nexsan disk costs
half as much as NetApp, for the same SATA disks.  With Nexsan, my overall
storage costs are less than half of a NetApp, for basically the same capability.
 The only "downside" is that I can't get all of the functionality in a single
head controller--however in many ways this is actually an advantage.  My total
costs

Re: [Dovecot] SSD drives are really fast running Dovecot

[Philipp Haselwarter]

"SH" == Stan Hoeppner  writes:

SH> Andrzej Adam Filip put forth on 1/15/2011 4:02 AM:
>> Stan Hoeppner  wrote:
>>> [...] The average size of an email worldwide today is less than 4KB,
>>> less than one typical filesystem block. [...]
>> 
>> Do not confuse "unix culture" of mostly plain text only email
>> messages with "MS Junk" culture of overblown formatting with
>> background images company logos as a few image files in every
>> (internal) email.

SH> "average size of an email worldwide"

SH> The bulk of all email is personal, not corporate: [...]

,
| More than 97% of all e-mails sent over the net are unwanted, according
| to a Microsoft security report.[39]
| 
| MAAWG estimates that 85% of incoming mail is "abusive email", as of the
| second half of 2007. The sample size for the MAAWG's study was over 100
| million mailboxes.[40][41][42]
| 
| Spamhaus estimates that 90% of incoming e-mail traffic is spam in North
| America, Europe or Australasia.[43] By June 2008 96.5% of e-mail
| received by businesses was spam.[18][unreliable source?]
`
http://en.wikipedia.org/wiki/E-mail_spam#As_a_percentage_of_the_total_volume_of_e-mail

---8<---[snipped 3 lines]---8<---
SH> under 4KB per message, especially considering the amount of SMS
SH> gatewaying going on with smart phones today.  Most of those are one
SH> liners with the smtp header being 4 times the size of the body, with
SH> total message size being under 1KB.

SH> -- Stan

I just have a tiny set of 4k spam mails, but they have an avg size of
39KB, ie well above 4KB.


-- 
Philipp Haselwarter

Re: [Dovecot] SSD drives are really fast running Dovecot

[Stan Hoeppner]

Andrzej Adam Filip put forth on 1/15/2011 4:02 AM:
> Stan Hoeppner  wrote:
>> [...] The average size of an email worldwide today is less than 4KB,
>> less than one typical filesystem block. [...]
> 
> Do not confuse "unix culture" of mostly plain text only email messages
> with "MS Junk" culture of overblown formatting with background images
> company logos as a few image files in every (internal) email.

"average size of an email worldwide"

The bulk of all email is personal, not corporate:  think Gmail, Hotmail, Yahoo,
the 50k ISPs worldwide, etc.  Average all of that together with the corporate
mail (small percentage), and you're well under 4KB per message, especially
considering the amount of SMS gatewaying going on with smart phones today.  Most
of those are one liners with the smtp header being 4 times the size of the body,
with total message size being under 1KB.

-- 
Stan

Re: [Dovecot] SSD drives are really fast running Dovecot

[Sven Hartge]

Andrzej Adam Filip  wrote:
> Sven Hartge  wrote:
>> Andrzej Adam Filip  wrote:
>>> Stan Hoeppner  wrote:

 [...] The average size of an email worldwide today is less than
 4KB, less than one typical filesystem block. [...]
>>
>>> Do not confuse "unix culture" of mostly plain text only email
>>> messages with "MS Junk" culture of overblown formatting with
>>> background images company logos as a few image files in every
>>> (internal) email.
>>
>> I just did a rough analysis of the mail spool of my university (6.000
>> users, students and faculty staff, about 10 million mails) and the
>> average mail size was at about 96KiB. Last year, this average was at
>> 77KiB and in 2009 we were at 62KiB.
>>
>> Mails the average size of 4KiB would then have been at a time when
>> MIME was not yet invented, I believe. Somewhere in 1994.

> I assume that in bigger organizations most mail stored in IMAP storage
> is internal. I also assume that size of typical mail in "unix/linux
> culture" and "MS culture" do differ. It may explain quite different
> experiences.

> Could you elaborate about penetration by MS software/culture
> (especially about MS Exchange) in your university?

Zero on the server side.

We have a central IT which handles all mail and so far no Exchange has
been requested. (Groupware features are handled by Egroupware.)

Many users of course use the mail client installed by default (which
would be Outlook or Live! Mail) and thus produce and receive HTML mails.
>From my Spamassassin statistics I can see about 50% of all incoming
mails are HTML mails, I guess the amount would be the same for outgoing
mails.

Grüße,
Sven

-- 
Sig lost. Core dumped.

Re: [Dovecot] Index files size calculation

[Timo Sirainen]

On 15.1.2011, at 21.08, Patrick Westenberg wrote:

> 2 or 3 weeks ago, one of you explained how to calculate the size of the
> index files for an user.

Someone did? .. It anyway depends on IMAP client and possibly also user. There 
are no easy ways to calculate it exactly. I think it's usually around 10-20% of 
mailbox size, but it really depends more on the number of messages than the 
size of messages.

[Dovecot] Index files size calculation

[Patrick Westenberg]

Hi guys,

2 or 3 weeks ago, one of you explained how to calculate the size of the
index files for an user.

Can somebody explain this again please?

Thx
Patrick

Re: [Dovecot] Web Based User Management

[Odhiambo Washington]

On Sat, Jan 15, 2011 at 4:30 PM, Thu Nguyen  wrote:

> Let try webmin. Not only creation/deletion but also configuration and many
> thing
>
>
Sure. We needed to dig more information from the OP before opening our large
mouths giving answers!


-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254733744121/+254722743223
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Damn!!

Re: [Dovecot] SSD drives are really fast running Dovecot

[Andrzej Adam Filip]

Sven Hartge  wrote:
> Andrzej Adam Filip  wrote:
>> Stan Hoeppner  wrote:
>
>>> [...] The average size of an email worldwide today is less than 4KB,
>>> less than one typical filesystem block. [...]
>
>> Do not confuse "unix culture" of mostly plain text only email messages
>> with "MS Junk" culture of overblown formatting with background images
>> company logos as a few image files in every (internal) email.
>
> I just did a rough analysis of the mail spool of my university (6.000
> users, students and faculty staff, about 10 million mails) and the
> average mail size was at about 96KiB. Last year, this average was at
> 77KiB and in 2009 we were at 62KiB.
>
> Mails the average size of 4KiB would then have been at a time when
> MIME was not yet invented, I believe. Somewhere in 1994.
>
> Grüße,
> Sven.

I assume that in bigger organizations most mail stored in IMAP storage
is internal. I also assume that size of typical mail in "unix/linux
culture" and "MS culture" do differ. It may explain quite different 
experiences.

Could you elaborate about penetration by MS software/culture (especially
about MS Exchange) in your university?

BTW I have seen a few (smaller) organizations with most (internal) mails
below 4KB but remaining *huge* mails capable to very significantly
influence average size. It makes me doubt about value of 
*bare* "average email size".

P.S. Anyway many organization are legally obliged to archive all emails.

-- 
[pl>en: Andrew] Andrzej Adam Filip : a...@onet.eu
Oh wearisome condition of humanity!
Born under one law, to another bound.
  -- Fulke Greville, Lord Brooke

Re: [Dovecot] SSD drives are really fast running Dovecot

[Bradley Giesbrecht]

On Jan 15, 2011, at 6:30 AM, Charles Marcus wrote:

One thing we are looking at here (small 50+ userbase) is kind of a  
'best
of both worlds' setup - using SSD's (haven't decided yet to trust a  
bare

striped set or go with a 4 drive RAID10 - probably the latter so I can
sleep at night) for the main OS and a limited amount of storage space
per user (maildir) for active/recent email, then use another namespace
with a much higher quota - I'm thinking about 10GB per user should  
do in

our environment - for 'slow' storage (cheap mechanical RAID10 setup) -
ie, emails that are only accessed on occasion (mdbox).

Then, enforce a smallish per user quota (how much would depend on your
particular environment, but I'm thinking something like 250 or maybe
500MB, since our users do get a lot of large attachments in the course
of doing business) on their INBOX - & Sent, Drafts and Templates  
folders

too, but that's a question on my list of 'how to do' - how to easily
place these 'special' folders on the 'fast' namespace, and all user
created folders in the 'slow' namespace. It would be really nice if
there were some kind of native way that dovecot could 'assign' the
'special' folders to the same namespace as the INBOX, and all other  
user

created folders to another...

Doing this will also help train users in proper email management -
treating their INBOX just like they would a physical INBOX tray on  
their

desk. They wouldn't just let paper pile up there, why do so in their
INBOX (because they 'can')? Ie, it should be something they should
always strive to keep totally EMPTY. Of course this practically never
happens, but the point is, they need to learn to make a decision once
they are finished with it, and most importantly, take said action -
either delete it, or file it.


Sounds like a great idea. I work with media companies where quotas can  
be challenging.


--
Brad

Re: [Dovecot] SSD drives are really fast running Dovecot

[Sven Hartge]

Andrzej Adam Filip  wrote:
> Stan Hoeppner  wrote:

>> [...] The average size of an email worldwide today is less than 4KB,
>> less than one typical filesystem block. [...]

> Do not confuse "unix culture" of mostly plain text only email messages
> with "MS Junk" culture of overblown formatting with background images
> company logos as a few image files in every (internal) email.

I just did a rough analysis of the mail spool of my university (6.000
users, students and faculty staff, about 10 million mails) and the
average mail size was at about 96KiB. Last year, this average was at
77KiB and in 2009 we were at 62KiB.

Mails the average size of 4KiB would then have been at a time when
MIME was not yet invented, I believe. Somewhere in 1994.

Grüße,
Sven.

-- 
Sig lost. Core dumped.

Re: [Dovecot] SSD drives are really fast running Dovecot

[Rick Romero]

Quoting Stan Hoeppner :

Rick Romero put forth on 1/14/2011 8:29 PM:

  >
  >> And that's assuming a platter squeezing in 1TB of data at
7200RPMs doesn't
  >> get a comparable performance improvement to a higher rotational
speed on a
  >> lower volume platter...
  >
  > Size and density are irrelevant.  Higher density will allow
greater streaming
  > throughput at the same spindle speed, _however_ this does
nothing for seek
  > performance.  Streaming performance is meaningless for
transaction servers.
  > IOPS performance is critical for transaction servers.  Seek
  > performance equals
  > IOPS performance.  The _only_ way to increase mechanical disk IOPS is to
  > increase the spindle speed the or the speed of the head
actuator.  If you've
  > watched mechanical drive evolution for the past 20 years you've seen that
  > actuator speed hasn't increased due to the physical properties
of voice coil
  > drive actuators.
  >
  >> Hell for the price of a single 250gb SSD drive,
  >> you can RAID 10 TEN 7200 RPM 500GB SATAs.
  >
  > I think your pricing ratio is a bit off but we'll go with it.  You'd
  > get 50,000
  > 4KB random IOPS from the SSD and only 750 IOPS from the RAID 10.  The
  > SSD could
  > handle 67 times as many emails per second for 10 times the cost.  Not
  > a bad trade.
  >
  >> So while, yes, my 10 drive SATA RAID 10 ONLY performs 166MB/sec with a
  >> 'simplistic' dd test, In reality I just don't think Joe User is going to
  >> notice the difference between that and the superior performance of a
  >> single SSD drive when he POPs his 10 3k emails.
  >
  > But Joe User _will_ notice a difference if this server with the RAID 10
  > mentioned above is supporting 5000 concurrent users, not just
Joe.  Responses
  > will lag.  With the SSD you can support 1 concurrent users
(assuming the
  > rest of the hardware is up to that task and you have enough RAM) and
  > responses
  > for all of them will be nearly instantaneous.  This is the difference
  > SSD makes,
  > and why it's worth the cost in many situations.  However, doing so
  > will require
  > an email retention policy that doesn't allow unlimited
  > storage--unless you can
  > afford than much SSD capacity.
  >
  > You can get 240,000 4k random IOPS and 1.9TB of capacity from two of
  > these in a
  > software RAID0 for $6,400 USD:
  > http://www.newegg.com/Product/Product.aspx?Item=N82E16820227665
  >
  > That's enough transactional IOPS throughput to support well over 50,000
  > concurrent IMAP users, probably far more.  Of course this would
  > require a server
  > likely on the order of at least a single socket G34 AMD 12 core
Magny Cours
  > system w/2GHz cores, 128GB of RAM, and two free PCIe X4/X8 slots
for the SSD
  > cards, based on a board such as this SuperMicro:
  > http://www.newegg.com/Product/Product.aspx?Item=N82E16813182240
  > (Actually this is the perfect board for running two of these
  > RevoDrive X2 cards)


I use pricewatch - so, yes, we may be talking refurb drives, but this is
not an issue when you're saving enough money to just buy a few more of
items you're already buying.

Also, if your filesystem is using 4k clusters, aren't you only using 1
random IOPS for a 4k email?   It just sounds to me like if you plan
'smarter', anyone can avoid the excessive costs of SSD and get 'end user
similar' performance with commodity hardware.

Rick

Re: [Dovecot] SSD drives are really fast running Dovecot

[Charles Marcus]

It would be nice if some of you could stop with the personal attacks.

While I agree that assuming that all users only receive 4K emails is not
realistic in most environments, neither is assuming a requirement of all
of the super-duper triple redundant hot fail-over for a mailstore with
no quota enforcing.

On 1/14/2011 11:16 PM, Stan Hoeppner wrote:
> But Joe User _will_ notice a difference if this server with the RAID 
> 10 mentioned above is supporting 5000 concurrent users, not just Joe.
> Responses will lag. With the SSD you can support 1 concurrent
> users (assuming the rest of the hardware is up to that task and you
> have enough RAM) and responses for all of them will be nearly
> instantaneous. This is the difference SSD makes, and why it's worth
> the cost in many situations. However, doing so will require an email
> retention policy that doesn't allow unlimited storage--unless you
> can afford than much SSD capacity.

One thing we are looking at here (small 50+ userbase) is kind of a 'best
of both worlds' setup - using SSD's (haven't decided yet to trust a bare
striped set or go with a 4 drive RAID10 - probably the latter so I can
sleep at night) for the main OS and a limited amount of storage space
per user (maildir) for active/recent email, then use another namespace
with a much higher quota - I'm thinking about 10GB per user should do in
our environment - for 'slow' storage (cheap mechanical RAID10 setup) -
ie, emails that are only accessed on occasion (mdbox).

Then, enforce a smallish per user quota (how much would depend on your
particular environment, but I'm thinking something like 250 or maybe
500MB, since our users do get a lot of large attachments in the course
of doing business) on their INBOX - & Sent, Drafts and Templates folders
too, but that's a question on my list of 'how to do' - how to easily
place these 'special' folders on the 'fast' namespace, and all user
created folders in the 'slow' namespace. It would be really nice if
there were some kind of native way that dovecot could 'assign' the
'special' folders to the same namespace as the INBOX, and all other user
created folders to another...

Doing this will also help train users in proper email management -
treating their INBOX just like they would a physical INBOX tray on their
desk. They wouldn't just let paper pile up there, why do so in their
INBOX (because they 'can')? Ie, it should be something they should
always strive to keep totally EMPTY. Of course this practically never
happens, but the point is, they need to learn to make a decision once
they are finished with it, and most importantly, take said action -
either delete it, or file it.

-- 

Best regards,

Charles

Re: [Dovecot] Web Based User Management

[Thu Nguyen]

Let try webmin. Not only creation/deletion but also configuration and many 
thing

Regards,
Thu Nguyen.

On Jan 15, 2011, at 2:47 PM, Odhiambo Washington  wrote:

> On Fri, Jan 14, 2011 at 11:14 PM, Matt  wrote:
> 
>> Does anyone know of a web GUI type application that would allow the
>> creation and deletion of email accounts on an email server?
>> 
> 
> 
> 1. Vexim 
> 2. Exim4u 
> 
> That is just because I use Exim, not Postfix.
> 
> -- 
> Best regards,
> Odhiambo WASHINGTON,
> Nairobi,KE
> +254733744121/+254722743223
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Damn!!

Re: [Dovecot] SSD drives are really fast running Dovecot

[Ed W]

One of the systems to fail was a firewall running off SSD.


SSD or CF?

It would appear it's also possible to damage some flash memory by 
powering off at the wrong moment?  I had a router running on a nearly 
new SLC flash card and it kept suffering errors every 24 hours and 
perhaps it was filesystem corruption since it was kind of fixed when I 
rebooted.  Then after a few more days it died completely, briefly I 
could repartition it and then an hour later I could no longer even get 
it detected to the OS and hence it appeared absolutely completely dead.


So that's a new 4GB SLC card, using around 500MB of it and a light 
writeable filesystem running pfsense (perhaps a few writes per minute) 
and it died inside a month...  I don't have enough data to see if it 
died from wear or if I was just unlucky...


This is a cheap (ish) CF card though, not an SSD drive

Ed W

Re: [Dovecot] SSD drives are really fast running Dovecot

[Andrzej Adam Filip]

Stan Hoeppner  wrote:
> [...] The average size of an email worldwide today is less than 4KB,
> less than one typical filesystem block. [...]

Do not confuse "unix culture" of mostly plain text only email messages
with "MS Junk" culture of overblown formatting with background images
company logos as a few image files in every (internal) email.

-- 
[pl>en: Andrew] Andrzej Adam Filip : a...@onet.eu
Let thy maid servant be faithful, strong, and homely.
  -- Benjamin Franklin

[Dovecot] fts squat: Disabled with in-memory indexes question

[Robert Schetterer]

Hi Timo , should i care of that ?
and what dous it mean

Jan 15 09:23:15 mail02 dovecot: lmtp(6847): Debug: fts squat: Disabled
with in-memory indexes
Jan 15 09:23:15 mail02 dovecot: lmtp(6847): Debug: fts: No backends
enabled by the fts setting


i have protocol

lmtp {
  # Space separated list of plugins to load (default is global
mail_plugins).
  mail_plugins = quota sieve virtual acl fts fts_squat mail_log notify
expire
}

so maybe having fts fts_squat here is not usefull ?

-- 
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria