Maildir en Mbox niet ideaal, waarom niet mail in DB?

[TD-er]

Op mijn werk heeft de mailserver het een beetje moeilijk. Mensen blijven om de 30sec pollen of er al nieuwe mail is (Pegasus mailclient via IMAP) en aangezien attachments van 20 MB hier echt geen uitzondering zijn, heeft de opslag (raid-setje) het nogal moeilijk.
Nu kan ik er wel gewoon meer geheugen indrukken (modules staan in bestelling), maar dat is natuurlijk ook maar een tijdelijke oplossing.
De gebruikers dicipline bijbrengen de grote attachments in een andere mailfolder te proppen werkt de eerste dag dat je dat tegen ze zegt, maar dan is dat ook weer vergeten.
Zoals uit het bovenstaande wel duidelijk is, werkt de mailserver nog met Mbox-files. Een logische overstap is natuurlijk om er maildirs van te maken, aangezien het toch via IMAP benaderd wordt.
Nadeel van maildirs is echter dat het zoveel opslagruimte kost en je filesysteem ook maar een beperkt aantal files aankan. (mischien dat dat met ReiserFS al niet meer meespeelt, daar heb ik nog niet naar gekeken) Naast die grote attachments komt er namelijk ook erg veel klein spul binnen, waardoor de blokgrootte van je filesysteem bepalend is voor de ruimte die de mailtjes innemen.

Nu zat ik te denken of het niet een idee is om de mailtjes zelf in een database te zetten en de attachments als files op de schijf op te slaan op een mail-dir-achtige manier en dan in de DB op te nemen welke attachments er in de mailtjes zaten.
Een voordeel is natuurlijk dat je dan geen uu-encoded data loopt op te slaan en dus ook minder schijfruimte kwijt bent voor de attachments.
De text die in de mailtjes staat is ook niet echt veel, over het algemeen, dus een echt grote belasting zal dat niet geven voor de DB-server.
Bijkomend voordeel is natuurlijk dat je in de database ook wat extra dingen kunt bijhouden, waardoor een aantal veel voorkomende IMAP-requests sneller afgehandeld kunnen worden (hoeveel mailtjes in die-en-die folder bijv)

Aangezien me dit zo onzettend logisch lijkt, kan ik me niet voorstellen dat dit nog niet veel eerder bedacht en uitgevoerd is.
Nu ben ik aan het zoeken geweest, maar het enige wat je met IMAP en MySQL tegenkomt is het eenvoudig beheren van virtuele domeinen.

Kortom weet iemand hier van een pakket wat bovenstaand idee ongeveer al in zich heeft, of is er duidelijk iets waardoor dit idee niet praktisch is, wat ik dus over het hoofd zie?

[Verwijderd]

Kijk eens naar DBMail (http://www.dbmail.org)

DBMail stopt alle mail (dus ook attachments) in een database. Er zitten daemons bij voor imap, pop3, lmtp en directe database injectie.
Da's dus niet helemaal wat je zelf voorstelt, maar eerlijk gezegd lijkt zo'n hybride oplossing (mail in database, attachments op disk) mij niet erg handig.

[TD-er]

Hmm die naam voor dat project is zo logisch dat ik mezelf wel voor het hoofd kan stoten dat ik 'm niet bedacht heb.

Maar goed, waarom vind je de attachments los opslaan niet handig?
Het enige nadeel wat ik kan bedenken is dat je in geval van een crash van de daemons mogelijk een consistency-check moet doen over of de attachment er nog staat en of die er nog moet staan.

[Verwijderd]

Ik denk dan vooral aan hoe de daemons (programmeer-) technisch in elkaar zouden gaan steken.
Deze moeten dan twee soorten 'drivers' hebben (voor DB en voor filesytem). Om een email te inserten of op te halen moeten die drivers beiden worden aangesproken en het resultaat weer worden samengevoegd in de respons naar de client. Dat maakt het allemaal niet efficienter en schoner...

Het lijkt mij het prettigst om alles op dezelfde plek te hebben (of DB, of FS). Daarnaast is het simpelweg niet nodig

[CyBeR]

TD-er schreef op dinsdag 11 oktober 2005 @ 12:12:
Hmm die naam voor dat project is zo logisch dat ik mezelf wel voor het hoofd kan stoten dat ik 'm niet bedacht heb.

Maar goed, waarom vind je de attachments los opslaan niet handig?
Het enige nadeel wat ik kan bedenken is dat je in geval van een crash van de daemons mogelijk een consistency-check moet doen over of de attachment er nog staat en of die er nog moet staan.

Omdat attachments gewoon onderdeel zijn van e-mails. Ze komen niet los aan ofzo, 't zit gewoon in de body. Als je dat los op wilt slaan moet je dus server-side die e-mail gaan zitten parsen op MIME headers, de attachment decoden, en dan opslaan. Om dan vervolgens de mail aan de client te serven moet je dat omgekeerd doen: de attachment encoden en weer achter de mail plakken. (Eventueel zou je 't decoden en encoden over kunnen slaan). Extra nadeel is dat je gegarandeerd elke vorm van PGP-achtige signatures over de zeik helpt.

[Wilke]

TD-er schreef op dinsdag 11 oktober 2005 @ 11:18:
Een logische overstap is natuurlijk om er maildirs van te maken, aangezien het toch via IMAP benaderd wordt. Nadeel van maildirs is echter dat het zoveel opslagruimte kost en je filesysteem ook maar een beperkt aantal files aankan. (mischien dat dat met ReiserFS al niet meer meespeelt, daar heb ik nog niet naar gekeken) Naast die grote attachments komt er namelijk ook erg veel klein spul binnen, waardoor de blokgrootte van je filesysteem bepalend is voor de ruimte die de mailtjes innemen.

Dat laatste zou met Reiserfs veel minder een probleem moeten zijn inderdaad. Misschien moet je het gewoon eerst eens testen daarmee, en kijken hoeveel ruimte het scheelt? Dus neem een testbak, kopieer al je mboxen, en converteer die naar maildir op een Reiserfs-partitie. En kijk dan hoeveel ruimte het inneemt. Dat de hoeveelheid ruimte significant uitmaakt kan ik me nog indenken; maar het aantal files zou met Reiserfs echt helemaal niets moeten uitmaken.

mbox2maildir scriptjes zijn op allerlei plaatsen te vinden...

Zie bv. ook IMAP benchmark. De conclusie (vergeleken met mbox):

Maildir + ReiserFS is a win on pretty much every front, and a significant improvement in several crucial operations (opening a new mailbox and deleting from a mailbox). The only loss is in search speed, and this can be improved by tweaking some FS options (turning off atime updates).

Search speed is wat minder snel, aangezien je heel veel files moet openen. Uiteraard scheelt het dan tijd als je de 'laatste access time' (atime) niet bijhoud; daarom verdient het aanbeveling op een maildir-partitie 'atime' updates uit te schakelen. Dit is een simpele optie in /etc/fstab bij het mounten van de partitie - 'noatime' ofzoiets).

[ Voor 26% gewijzigd door Wilke op 11-10-2005 13:38 ]

[Confusion]

Je kan toch maatregelen treffen zodat polls genegeerd worden als ze te snel na de vorige komen?

[TD-er]

Dat splitsen en weer opbouwen van de mailtjes wanneer er een attachment aan zit, leek me logisch.
Ik had echter niet aan PGP enzo zitten denken, al zou dat met wat puzzelen ook wel weer goed kunnen komen. Bijv scheiden van texten uit de mailtjes en die heel licht gzippen zodat je toch exact hetzelfde kunt reconstrueren en toch die UUE-overhead kwijt bent.

Maar goed, ik zal van de week eens gaan benchmarken met maildir en mboxen op een systeempje hier.
* TD-er heeft heel toevallig net van de week een oud systeempje geconfisceerd voor testdoeleinden

[TD-er]

Confusion schreef op dinsdag 11 oktober 2005 @ 13:55:
Je kan toch maatregelen treffen zodat polls genegeerd worden als ze te snel na de vorige komen?

Jawel, maar dan krijg je met PegasusMail al vrij snel een schermpje in beeld met "server error" of een iets andere minder subtiele melding en dan bezorg ik mezelf alleen maar meer werk.
Daarnaast wil ik ook niet echt als BOFH overkomen hier op mijn werk.

[Wilke]

TD-er schreef op dinsdag 11 oktober 2005 @ 14:01:
Maar goed, ik zal van de week eens gaan benchmarken met maildir en mboxen op een systeempje hier.
* TD-er heeft heel toevallig net van de week een oud systeempje geconfisceerd voor testdoeleinden

Okee, maar naar performance (snelheid) kijken is op een niet-representatief systeem (lees: oude hardware) waarschijnlijk minder boeiend. Dat maildir dat wint is denk ik al vaak genoeg gebenchmarked (i.h.b. als je reiser of XFS of dergelijke gebruikt, iig geen ext3).

Wat wel interessant is, en waar ik zo snel niks over kon vinden op internet, is het vergelijken van de hoeveelheid gebruikte ruimte op de HD. Als je daar een redelijk verhaal over schrijft heb je wellicht sowieso een leuk artikel om ergens op internet te publiceren?

Tip: splitsen van mailtjes zou ik niet aan beginnen als je jezelf een hoop ellende wilt besparen.

[TD-er]

Ik zal komende week eens kijken wat het aan ruimte scheelt.
Het idee dat ik dat op een oud computertje wilde testen, is omdat je dan wel degelijk van de opslag afhankelijk bent. Een machine met genoeg geheugen is wat lastig benchen wat betreft dergelijke verschillen ivm caching enzo.
Maar je hebt gelijk, een simpele google-opdracht naar maildir vs mbox levert al wel wat op.

[Confusion]

TD-er schreef op dinsdag 11 oktober 2005 @ 14:04:
Jawel, maar dan krijg je met PegasusMail al vrij snel een schermpje in beeld met "server error" of een iets andere minder subtiele melding en dan bezorg ik mezelf alleen maar meer werk.
Daarnaast wil ik ook niet echt als BOFH overkomen hier op mijn werk.

Dat moet je inderdaad vermijden. Ik bedoelde dat je gewoon een 'no new mail'-boodschap terugstuurt, zonder daadwerkelijk te controleren of er new mail is. Alleen als controleren wanneer de laatste poll was minder resources kost dan daadwerkelijk controleren of er nieuwe mail is natuurlijk .

[_JGC_]

Je kunt ook naar Cyrus IMAP kijken, die presteert niet beroerd met veel en grote mailboxes. Heb voor 650 domeinen een mailserver draaien:

P3 1,13GHz
1,5GB PC133 ECC Registered geheugen
3x36GB 10K RPM SCSI
IBM ServeRAID 4/Lx RAID

Debian Sarge
2.6 kernel
Cyrus IMAP 2.2
Postfix 2.x
OpenLDAP 2.2
Spamassassin + Clamav + Amavis
Filesystem: XFS

Load loopt bij dikke mailbommetjes wel eens naar de 20-30, maar die 100.000 pop logins die dat ding per dag krijgt doet ie met 2 vingers in de neus nog wel. Heb mijn eigen mail met IMAP op dat ding lopen, ik merk eigenlijk weinig vertraging in vergelijking met mijn eigen oude server (Duron 700, 768MB geheugen en 1 domein )

Cyrus IMAP gebruikt een soort van Maildir, maar dan net iets anders. Er wordt ontzettend veel gecached en geindexeerd, wat het geheel een heel stuk sneller maakt. Verder is cyrus een van de meest complete IMAP implementaties die er te krijgen is.


Wat betreft duizenden kleine bestandjes: ben er met XFS nog niet op gestuit met 600 domeinen, dus dat zal wel wat meevallen. Overigens is XFS sneller in dit karweitje dan Reiserfs, die viel mij vies tegen. Persoonlijk denk ik dat je beter uit de voeten kunt met Ext3 en Directory Indexing en evt full data journalling erbij. XFS is niet echt een topper als het om veel kleine rotbestandjes gaat, ext3 doet dit met directory indexing al een heel stuk beter.

[TD-er]

@_JGC_:
650 mail-domeinen. Dan hebben die mensen waarschijnlijk een mail-quota. Dus die zullen iets minder snel ook hun mail op die server bewaren vermoed ik, zeker als daar attachments aanzitten.
Maar goed, best impressive dat zo'n machine dat inderdaad allemaal aankan.

Heb je ook een schatting hoeveel mailtjes er per dag binnenkomen op die machine en hoe veel ruimte de mail ongeveer inneemt?
Op mijn werk krijgen we namelijk nogal wat spam mail binnen (3000+ per dag voor een bedrijfje van amper 15 man) en ze willen die spam ook gedurende een tijdje bewaren voor het geval iets vals geidentificeerd is. Vandaar dat ik een beetje bang ben voor een max aantal files op het filesysteem. (100'000 files is 1 maand)

[_JGC_]

meer dan 500 van die domeinen zijn geconverteerd van een qmail-vpopmail systeem waar nooit quota op gestaan heeft. Gebruikers die stom en onnozel doen checken elke 10 seconden hun account met POP3, anderen gebruiken gewoon IMAP zoals het hoort.

We gebruiken nogal eens wat headerchecks, RBLs en dat soort dingen in postfix waardoor veel troep niet eens aan het spamfilter toekomt. Verder gebruiken we recipient maps, waarbij postfix controleert of een gebruiker bestaat of niet. Catchall mailboxes hebben we met de conversie afgeschaft, bestaande gebruikers hebben catchall behouden indien aanwezig, maar nieuwe gebruikers zullen het moeten doen met een onbeperkt aantal instelbare aliasen.

Als ik zo kijk in de maillog van gisteren:
# cat mail.log.0 | grep lmtpunix | grep commit -c
7472

Verder is er op dit moment van de 63GB spoolpartitie die we hebben slechts de helft in gebruik. Hierbij in je achterhoofd houdend dat die server geen nieuwe klanten meer krijgt, die worden allemaal aangemaakt op de 2e mailserver die een maand geleden in werking is gezet (helaas werkte clustering niet zoals we het wilden, dus is het weer een standalone cyrus server geworden ). Overigens is die 63GB partitie ook gewoon het hele /var filesystem, dus die helft in gebruik wordt gedeeld met logfiles en natuurlijk de amavis quarantine directory met daarin bakken vol spam (dat spaart in een dag zo goed dat je met rm * er niet doorheen komt )

[zeroxcool]

_JGC_ schreef op dinsdag 11 oktober 2005 @ 23:50:
Verder is er op dit moment van de 63GB spoolpartitie die we hebben slechts de helft in gebruik. Hierbij in je achterhoofd houdend dat die server geen nieuwe klanten meer krijgt, die worden allemaal aangemaakt op de 2e mailserver die een maand geleden in werking is gezet (helaas werkte clustering niet zoals we het wilden, dus is het weer een standalone cyrus server geworden ). Overigens is die 63GB partitie ook gewoon het hele /var filesystem, dus die helft in gebruik wordt gedeeld met logfiles en natuurlijk de amavis quarantine directory met daarin bakken vol spam (dat spaart in een dag zo goed dat je met rm * er niet doorheen komt )

Slightly offtopic :

code:

find /var/spool/qmailscan/quarantine/new -name \* -mtime +2 -exec rm {} \;

Trasht de quarantine van 2 dagen geleden...

[ Voor 5% gewijzigd door zeroxcool op 12-10-2005 19:29 . Reden: smilie werkte niet ]