Uitgaande post kopiëren. Bulkleeging van prullenbakken in de postfix-maildatabase

Datum: 08-06-2010

Gegeven:
1) Mailgateway ingeschakeld achtervoegsel voor interne mail, beschermd tegen spam, etc.
2) Interne post op elk gewenst adres mailserver, met lokale gebruikers.

Taak:
Er is een medewerker met een interne mailbox en een externe. Het is noodzakelijk om alle brieven die afkomstig zijn door te sturen/kopiëren externe omgeving naar de lokale mailbox en naar de externe mailbox.
Oplossing:
Opening configuratiebestand Postfix.
vi /etc/postfix/main.cf
Voeg een regel toe
receiver_bcc_maps = hash:/etc/postfix/recipient_bcc
Maak een bestand
vi /etc/postfix/recipient_bcc
Toevoegen:

Er staat dat voor gegeven gebruiker stuur alle e-mail door naar \n [e-mailadres beveiligd] Dit e-mailadres beschermd tegen spambots. Om het te zien, moet JavaScript zijn ingeschakeld en ingeschakeld lokale post berichten worden nog steeds afgeleverd.
Als resultaat krijgen we:
Brieven komen intern binnen postadres\N [e-mailadres beveiligd] Dit e-mailadres is beschermd tegen spambots. Om deze te kunnen bekijken, moet JavaScript zijn ingeschakeld en naar buiten \N [e-mailadres beveiligd] Dit e-mailadres is beschermd tegen spambots. Om deze te kunnen bekijken, moet JavaScript zijn ingeschakeld
Vervolgens zullen we doen:
postmam /etc/postfix/recipient_bcc


Aanvullend:
Voor binnenkomende post kopiëren oplocal.loc naar mailbox\N [e-mailadres beveiligd] Dit e-mailadres is beschermd tegen spambots. Om deze te kunnen bekijken, moet JavaScript zijn ingeschakeld
In vi /etc/postfix/recipient_bcc schrijven we
@lokaal.loc\n [e-mailadres beveiligd] Dit e-mailadres is beschermd tegen spambots. Om deze te kunnen bekijken, moet JavaScript zijn ingeschakeld
Om te kopiëren gehele domein in \n [e-mailadres beveiligd] Dit e-mailadres is beschermd tegen spambots. Om deze te kunnen bekijken, moet JavaScript zijn ingeschakeld
toevoegen aan /etc/postfix/main.cf

altijd_bcc=\n [e-mailadres beveiligd] Dit e-mailadres is beschermd tegen spambots. Om deze te kunnen bekijken, moet JavaScript zijn ingeschakeld

Uitgaande post kopiëren

IN /etc/postfix/main.cf toevoegen:
sender_bcc_maps = hash:/etc/postfix/sender_bcc
Maak een bestand:
vi /etc/postfix/sender_bcc
\N [e-mailadres beveiligd] Dit e-mailadres is beschermd tegen spambots. Om het te kunnen zien, moet JavaScript zijn ingeschakeld \n [e-mailadres beveiligd] Dit e-mailadres is beschermd tegen spambots. Om deze te kunnen bekijken, moet JavaScript zijn ingeschakeld

Vervolgens zullen we doen:
postmam /etc/postfix/sender_bcc


Er was een taak van het management: u moet een back-up maken van alle e-mail met de mogelijkheid deze later te bekijken,
als er plotseling een slechte situatie ontstaat met een medewerker.
Zo gezegd zo gedaan.

Dus... aangezien ik postfix+cyrus-imap als mailserver gebruik, heb ik geprofiteerd van de interne mogelijkheden van beide systemen, namelijk:
1. Postfix kan alle passerende e-mail naar een bepaalde mailbox kopiëren
2. cyrus-imap heeft een implementatie van zeef

Ik heb mezelf de volgende taak gesteld:
1. Een brief die door de server gaat, wordt naar de mailbox gekopieerd [e-mailadres beveiligd]
2. Sieve-script verwerkt de brief en plaatst deze in de juiste mailboxmap [e-mailadres beveiligd]

Acties:
1. Voeg een regel (parameter) toe aan /etc/postfix/main.cf
altijd_bcc = [e-mailadres beveiligd]

2. Omdat ik ook amavisd-new gebruik, moet ik één regel toevoegen
in \etc\postfix\master.cf om dubbele e-mails te voorkomen
-o receiver_override_options=no_address_mappings

3. Dus het kopiëren is voltooid, laten we nu specifiek omgaan met de back-upbox (maak eerst een back-upgebruiker in het systeem aan zonder rechten en zonder bash)
# cyradm -u cyrus localhost --auth PLAIN-TLS
IMAP-wachtwoord:
mskgw.masterlock.ru> cm user.backup #maak de box zelf

# maak submappen voor de testbox
mskgw.masterlock.ru> cm user.backup.test.inbox
mskgw.masterlock.ru> cm user.backup.test.sent
Hier denk ik dat het duidelijk is: inbox is voor inkomend, verzonden is voor uitgaand.

4. Alles in de brievenbus is klaar voor gebruik, nu moet je een zeefscript maken zodat de brieven netjes in mappen worden ingedeeld.
In de map /var/lib/imap/sieve maken we het backup.script-script
# vi /var/lib/imap/sieve/backup.script

vereisen ["bestand in", "subadres"];

if adres:gebruiker ["naar", "cc", "bcc"] "test" (
bestand in "user.backup.test.inbox";
}
if adres:gebruiker "van" "test" (
bestand in "user.backup.test.sent";
}
Dit script controleert of de brief bij ons is aangekomen of ons verlaat, en dienovereenkomstig:
plaatst het in een specifieke map.

5. Nu moet je dit script op het systeem toepassen. Verbinden met zeef - u moet verbinding maken
user-box waarin het script moet worden uitgevoerd.
!!!LET OP - schakel voor de zekerheid de postfix-service uit, anders kan er een probleem optreden met de cyrus-imap - delivery en tls_sessions databases

#sieveshell -u backup -een backup localhost

>put /var/lib/imap/sieve/backup.script backup.script #importeer het script onder de naam backup
>activeer backup #activeer het script - zonder activering zal het script niet werken
> stoppen
Als er geen fouten optreden, kunt u testen.

6. Testen
Maak verbinding met uw mailbox [e-mailadres beveiligd]
a) In de brievenbus [e-mailadres beveiligd] maak een brief, verzend deze - de brief zou moeten verschijnen
in de map test.sent van de back-upbox
b) Vanuit elke brievenbus sturen we een brief naar de brievenbus [e-mailadres beveiligd]- de brief zou moeten verschijnen
in de map test.inbox van de back-upbox

Als alles in orde is, dan goed gedaan.

Nadelen:
- voor elke gebruiker moet u handmatig submappen aanmaken
- voor elke gebruiker moet u het script opnieuw genereren, d.w.z. bewerk het bestand en download het vervolgens opnieuw via sievshell (als u het onder dezelfde naam downloadt, is activering van het script niet vereist)
- in de gaten moeten houden vrije ruimte op een server, anders eindigt het misschien... :)
Succes!

Ik moet veel werken met postfix-gebaseerde mailservers met een maildatabase in maildir-formaat. Gedurende een aantal jaren werk, velen diverse technieken voor optimalisatie en configuratie. Vandaag heb ik besloten om alle min of meer universele en nuttige scripts samen te stellen voor automatische reiniging maildatabase in postfix.

Dit artikel is relevant voor degenen die het hebben voltooid of gebruikt afgewerkte montage aan de basis. Dit betreft de materialen op mijn site. Over het algemeen is alles wat hieronder wordt beschreven relevant voor elke mailserver die e-mail in het formaat opslaat maildir.

Ik zal een paar woorden zeggen over waarom maildir . Persoonlijk gebruik ik dit formaat vanwege het gemak. Elke letter erin is dat apart bestand, die door iedereen kan worden bekeken teksteditor. Het is handig om een ​​back-up van deze bestanden te maken, de inhoud te analyseren en ze op basis van bepaalde criteria te sorteren. Over het algemeen kunt u ermee werken zoals met gewone tekstbestanden. Op basis van deze voordelen wordt alles gedaan verder werk in het artikel. Ik zie slechts één nadeel: er worden een groot aantal kleine bestanden gemaakt zware belasting naar het schijfsubsysteem.

Voor de duidelijkheid zal ik een voorbeeld geven waarmee u de belasting van de schijven kunt schatten. Om mee te synchroniseren rsync gebruiken maildatabase met een volume van ongeveer 1 terabyte, gelegen op raid10 regular 3.5 sata-schijven, op één identieke schijf voor back-up, duurt het ongeveer een paar uur, voornamelijk om bestanden tussen de bron en de bestemming te vergelijken. Het kopiëren van bestanden zelf gaat snel, maar om veranderingen in de loop van een dag te vergelijken, moet je een langdurige handeling uitvoeren. Tegelijkertijd is het werk van gebruikers (~30-40 personen) met deze database over het algemeen redelijk comfortabel, er zijn geen obstakels waargenomen.

Dat wil zeggen dat voor zo'n aantal gebruikers de server in feite een gewone desktopcomputer kan zijn met 2-4 gewone sata-schijven. De prestaties van elke processor en ongeveer 2-4 gigabyte zijn voldoende RAM. Aparte vraag uiteraard aan de betrouwbaarheid van een conventionele systeemeenheid. Ik raad niet aan om er servers op te bouwen, maar als je dat echt wilt, kan dat.

De volgende scripts voor het opschonen van de maildatabase zijn geschreven verschillende tijden op verschillende servers. Soms lijkt het erop dat alles onlogisch of op de een of andere manier ingewikkeld is gedaan. Er ontstonden vaak omslachtige constructies als er problemen waren met spaties of speciale tekens in mapnamen in het Russisch, die, wanneer ze worden vertaald in UTF-7 (de codering van imap-mapnamen in duiventil), veranderen in strings die erg lastig te verwerken zijn. Verder zal het duidelijk zijn wat ik bedoel.

Laten we nu verder gaan met specifieke voorbeelden.

Verwijder eenvoudig oude e-mails uit uw mailbox

Laten we beginnen met het eenvoudigste voorbeeld. Stel dat u een soort brievenbus heeft waarin het geen zin heeft om brieven te bewaren die ouder zijn dan een bepaalde periode. Dit kan bijvoorbeeld een notificatiebox voor een monitoringsysteem zijn. Zodra een waarschuwing is gelezen, is deze niet langer relevant. Alle gebeurtenissen worden al opgenomen en opgeslagen op de server zelf, dus het heeft geen zin om brieven lange tijd op te slaan. Laten we deze mailbox leegmaken door alle brieven te verwijderen die ouder zijn dan 30 dagen.

/usr/bin/find /data/mail/virtual/ [e-mailadres beveiligd]/Maildir/*/ -type f -mtime +30 -exec rm () \;

IN in dit geval we gebruiken gewoon de standaard syntaxis van het hulpprogramma om naar bestanden te zoeken vinden. Details over het gebruik ervan zijn te vinden op internet, er zijn tal van voorbeelden. Bij het debuggen raad ik aan om geen delete te gebruiken, maar de uitvoer eenvoudigweg naar een bestand te pipen, zodat je kunt evalueren wat het hulpprogramma heeft gevonden en op het punt staat te verwijderen. IN eenvoudige voorbeelden Op deze manier lijkt het misschien dat het geen zin heeft om te controleren, maar bij complexere ontwerpen raad ik je aan om het bijvoorbeeld altijd zo te doen.

/usr/bin/find /data/mail/virtual/ [e-mailadres beveiligd]/Maildir/*/ -type f -mtime +30 >> /root/dellist.txt

Kijk daarna naar het bestand /root/dellist.txt en controleer wat u gaat verwijderen. Na controle is het niet nodig om opnieuw in de database te zoeken en de schijven opnieuw te laden. U kunt alle opgegeven gegevens verwijderen dellist.txt letters met het volgende script.

#!/bin/bash cat /root/dellist.txt | terwijl ik lees; doe rm -f "$i" klaar

Het zoekproces zelf maildatabase postfix is ​​niet zo tijdrovend als zoeken en verwijderen. Bij zwaarbelaste databases raad ik aan de verwijdering uit te voeren wanneer de server het minst belast is, en op elk gewenst moment te zoeken. Natuurlijk is het ook beter om buiten werktijd te zoeken, maar ik hou er niet van om 's nachts te werken, dus ik doe overdag alles wat ik kan en laat 's nachts zo min mogelijk werk achter.

Bulkleeging van prullenbakken in de postfix-maildatabase

Laten we naar een complexer voorbeeld kijken. We moeten automatisch alle prullenbakken van gebruikers verwijderen van e-mails die ouder zijn dan 30 dagen. Ik raad aan om deze schoonmaak altijd in te stellen. Het is een feit dat als de server zwaar belast wordt, deze de inhoud van de prullenbak niet altijd correct verwijdert. Een gebruiker heeft bijvoorbeeld veel e-mails naar de prullenbak gestuurd (tienduizenden), op ‘prullenbak legen’ geklikt en gesloten mail imap cliënt. De mogelijkheid bestaat dat de e-mails niet daadwerkelijk worden verwijderd, maar gewoon in de prullenbak blijven hangen. Imap-server Dovecot verwijdert brieven niet onmiddellijk, maar plaatst ze in een wachtrij en verwijdert ze langzaam. Soms wordt dit proces onderbroken en vindt de verwijdering niet plaats. U kunt dit opnieuw proberen. Vroeg of laat worden ze verwijderd.

Er zijn gebruikers die door de jaren heen hun prullenbakken niet zelf legen, ze verzamelen daar een aanzienlijke hoeveelheid nutteloze e-mails, die alleen maar ruimte in beslag nemen op de server en het werk van dezelfde back-ups of opschoonscripts vertragen. We hebben hulp nodig om voor eens en voor altijd afstand te doen van deze post.

De moeilijkheid bij het legen van prullenbakken is dat er veel mapnamen kunnen zijn voor verwijderde e-mail. Elke e-mailclient maakt zijn eigen map aan, waarvan de naam mogelijk niet samenvalt met bestaande mappen. Nu kunnen 3 soorten e-mailclients tegelijkertijd worden gebruikt: web, desktop of mobiel programma. Elk van hen maakt zijn eigen set mappen. Bovendien worden Russische imap-mapnamen opgeslagen in UTF-7-codering, wat het werk van scripts bemoeilijkt. Speciale tekens en spaties moeten worden geëscaped.

Hier is mijn lijst met mogelijke mapnamen voor externe e-mail.

#!/bin/bash # huidige datum in jaar-maand-dag formaat data=`date +"%Y-%m-%d"` # vormt een lijst brievenbussen zoeken naar mailbox=`ls -l /data/mail/virtual | grep vmail | awk "(print $9)"` voor box1 in $mailbox do /usr/bin/find /data/mail/virtual/$box1/Maildir/".&BCMENAQwBDsENQQ9BD0ESwQ1-"/*/ -type f -mtime +30 | terwijl je een ; do ls "$a" >> /root/mailclean/trashclean-log/$data.txt klaar gedaan voor box2 in $mailbox do /usr/bin/find /data/mail/virtual/$box2/Maildir/".Verwijderd Berichten"/*/ -type f -mtime +30 | terwijl je b leest; do ls "$b" >> /root/mailclean/trashclean-log/$data.txt klaar gedaan voor box3 in $mailbox do /usr/bin/find /data/mail/virtual/$box3/Maildir/.Trash/ */ -type f -mtijd +30 | terwijl je c leest; do ls "$c" >> /root/mailclean/trashclean-log/$data.txt klaar gedaan voor box4 in $mailbox do /usr/bin/find /data/mail/virtual/$box4/Maildir/".&BCMENAQwBDsENQQ9BD0ESwQ1 - &BE0EOwQ1BDwENQQ9BEIESw-"/*/ -type f -mtijd +30 | terwijl je d leest; do ls "$d" >> /root/mailclean/trashclean-log/$data.txt klaar gedaan voor box5 in $mailbox do /usr/bin/find /data/mail/virtual/$box5/Maildir/".&BBoEPgRABDcEOAQ9BDA -"/*/ -type f -mtijd +30 | terwijl je e leest; do ls "$e" >> /root/mailclean/trashclean-log/$data.txt klaar gedaan voor box6 in $mailbox do /usr/bin/find /data/mail/virtual/$box6/Maildir/".Verwijderd Artikelen"/*/ -type f -mtime +30 | terwijl je f leest; do ls "$f" >> /root/mailclean/trashclean-log/$data.txt gedaan gedaan cat /root/mailclean/trashclean-log/$data.txt | terwijl ik lees; doe rm -f "$i" klaar

Voor de compactheid zouden we hier natuurlijk nog een geneste lus kunnen maken en de mapnamen kunnen doorlopen. Ik heb dit niet gedaan voor de duidelijkheid. Bovendien is de lijst klein, je kunt hem zo laten. Enkele opmerkingen over het script.

Ontwerp

Mailbox=`ls -l /data/mail/virtueel | grep vmail | awk "(afdruk $9)"`

genereert een lijst met vakken die moeten worden opgeschoond. In dit geval worden alle bestaande dozen gebruikt. vmail hier is de eigenaar van de mappen met dozen. U kunt een lijst met huidige mailboxen krijgen op verschillende manieren. Ik deed het zo. U kunt handmatig een lijst met vakken samenstellen in een tekstbestand in de indeling één vak per vak nieuwe lijn en werk volgens uw lijst. Iets als dit:

Mailbox=/root/mailclean/mailboxlist.txt

Misschien moet het pad naar het bestand tussen aanhalingstekens worden gezet, ik weet het nu niet precies meer, ik moet het controleren. Ik log lijsten met verwijderde e-mails voor het geval dat, zodat ik ze snel uit het archief kan herstellen verwijderde e-mails, als het plotseling nodig wordt. Tijdens het debuggen raad ik aan commentaar te geven laatste fase het script waarin de verwijdering wordt uitgevoerd. Om te beginnen maakt u eenvoudigweg een lijst met bestanden die u wilt verwijderen en zorgt u ervoor dat daar niets onnodigs in staat en dat het zoeken in de mappen correct is uitgevoerd.

U kunt op dezelfde manier ook uw spammappen wissen. Hier is mijn lijst voor dergelijke mappen.

Meer gedetailleerde vraag automatische verwijdering We zullen spam afzonderlijk beschouwen.

E-mails verwijderen op basis van e-mailinhoud

Laten we verder gaan met nog meer complex voorbeeld, maar in de eenvoudigste wijziging. Stel dat u alle brieven die aan een bepaald adres zijn gericht, moet verwijderen. Dit kan relevant zijn in gevallen waarin een alias wordt gebruikt en van daaruit wordt omgeleid naar veel mailboxen. Als gevolg hiervan worden brieven die aan deze alias zijn gericht, verspreid over de gehele postbasis verschillende dozen. Tegelijkertijd verliezen deze brieven na verloop van tijd hun relevantie en is het niet nodig om ze op te slaan.

IN in dit voorbeeld Ik zal nog een complicatie maken. We zullen niet alleen alle verwijderingen van brieven uit de database registreren, we zullen ze ook opslaan en in mappen ordenen met de namen van de mailboxen waaruit ze zijn verwijderd. Bovendien worden verwijderde berichten opgeslagen in mappen met namen in de vorm van de verwijderingsdatum. Zo verzekeren wij ons volledig tegen verwijdering de benodigde brief. Zelfs als dit gebeurt, kunnen we deze verwijderde brief snel terugvinden. Bovendien leggen we de begin- en eindtijd van het zoeken en verwijderen vast in het logbestand. Omdat het zoeken naar inhoud behoorlijk lang duurt, raad ik aan de uitvoeringstijd in de gaten te houden, zodat het in vensters met een lage serverbelasting past.

#!/bin/bash # maak een lijst met mailboxen die moeten worden opgeschoond mailbox=`ls -l /data/mail/virtual | grep vmail | awk "(print $9)"` # datum in het formaat Jaar-maand-dag_uur-minuut-seconde data_full=`date +"%Y-%m-%d_%H-%M-%S"` # datum in de formaat Jaar -maand-dag data=`datum +"%Y-%m-%d"` # map voor het opslaan van kopieën van verwijderde berichten copydir=/backup/mailclean # adres van het logbestand met informatie over de looptijd van de script logbestand=/backup/mailclean/log.txt echo "============`datum +"%Y-%m-%d"`=========== =" >> $logfile echo " `date +"%H-%M-%S"` Start mail opschonen" >> $logfile voor box in $mailbox do # mappen aanmaken met mailboxnamen en huidige datum voor kopieën van verwijderde brieven mkdir -p $copydir/$box/mail/$data # maak een lijst met alle letters in de mailbox /usr/bin/find /data/mail/virtual/$box/Maildir -type f -name "*mailsrv* " -mtime +30 -daystart | terwijl je een ; do # zoek het adres van de ontvanger in de inhoud van de brief [e-mailadres beveiligd] en schrijf de namen van dergelijke letters in een afzonderlijk bestand voor elke mailbox grep -E -R -l -I "*for ;*" "$a" >> $copydir/$box/copy-$data_full.txt done # schrijf de naam van de box naar het algemene logbestand echo "=========$box=== ==== ==" >> $copydir/$data_full-all.txt # schrijf alle verwijderde berichten uit elke mailbox voor een specifieke opschoondatum naar een gemeenschappelijk logbestand cat $copydir/$box/copy-$data_full.txt > > $copydir/$data_full-all.txt # maak een lijst met mailboxberichten om cat $copydir/$box/copy-$data_full.txt te verwijderen tijdens het lezen i # kopieer de e-mail van de echte mailbox naar de archiefmap (Ik raad aan om dit te gebruiken tijdens het debuggen) cp -p "$ i" $copydir/$box/mail/$data # verplaats de brief van de echte mailbox naar het archief (gebruik na het debuggen) # mv "$i" $copydir/ $box/mail/$data done done # registreer de voltooiingstijd van de script-echo "`date +"%H-%M-%S"` End mail clean" >> $logfile echo "======= ================================ =========" >> $logbestand

Laat me de belangrijkste punten toelichten. In de lijn met het zoeken naar letters in de brievenbus is er een masker:

/usr/bin/find /data/mail/virtual/$box/Maildir -type f -naam "*mailsrv*"-mtijd +30 -dagbegin | terwijl je een ; Doen

In dit geval maakt mailsrv deel uit van de servernaam. In het maildir-formaat bevatten de namen van mailbestanden altijd de servernaam. Met dit masker kunt u alleen e-mailbestanden vinden en eventuele andere servicebestanden negeren. En ze zullen er zeker zijn, bijvoorbeeld duiventilindexen, zeefregels, enz. Vergeet niet om dit masker in uw eigen masker te veranderen in overeenstemming met de servernaam.

Tekenreeks om de ontvanger van de brief te zoeken *voor ;* precies in deze vorm overgenomen servicekoppen. Zelfs als brieven door verschillende filters naar andere mailboxen worden verplaatst, wordt de oorspronkelijke ontvanger van de brieven nog steeds door deze lijn geregistreerd.

Ik waarschuw je dat je dit en andere scripts niet blindelings moet gebruiken. Ze worden voornamelijk gegeven om de principes en ideeën te laten zien die ik gebruik. U moet deze scripts zorgvuldig bekijken, begrijpen wat er in elke regel gebeurt en ze aanpassen aan uw behoeften. IN afgewerkte vorm Het is onwaarschijnlijk dat u precies zo'n script nodig heeft. Alles is hier heel individueel en vereist bewustzijn van alle uitgevoerde acties.

Als u automatisch alle spambrieven uit uw e-mailarchief wilt verwijderen die door uw antispamsysteem als spam zijn gemarkeerd, kunt u de serviceheader gebruiken die dit systeem instelt. Kaspersky Antispam markeert bijvoorbeeld alle spam-e-mails als volgt:

X-KLMS-AntiSpam-Status: spam

Daarom zoek ik naar alle letters met zo'n serviceheader en doe ik er iets mee. Ik verplaats het bijvoorbeeld naar de spammap of verwijder het. Maar hier moet je voorzichtig zijn en alles zorgvuldig doen. Als het filter bijvoorbeeld bepaalde e-mails ten onrechte als spam heeft gemarkeerd, kan de gebruiker deze niet opslaan als u deze e-mails automatisch verwijdert. Hier moet je even over nadenken specifieke situatie wat te doen. Op huidige moment Ik gebruik dit soort regels niet om e-mail te verwijderen of te verplaatsen, alleen voor zoekopdrachten om de hoeveelheid spam-mail te schatten. Als het te groot is en het wordt schoongemaakt, komen er aanzienlijke volumes vrij schijfruimte, dan ga ik iets doen met gebruikersboxen. Meestal zijn lokale beheerders gespannen, zodat ze gebruikers aanmoedigen om zelfstandig te werken handmatige reiniging spam. Als er niet veel spam is, doe ik gewoon niets.

E-mails filteren op basis van e-mailonderwerp

Laten we er nog meer overwegen moeilijke optie vorig script. Daar filterden we brieven op basis van de inhoud van serviceheaders. Maar als we de post willen filteren op het onderwerp van de brief, kunnen we niet meteen iets doen. Er ontstaan ​​problemen met de onderwerpregel van de e-mail vanwege het feit dat deze is gecodeerd in base64 als de Russische taal wordt gebruikt. Hier is een eenvoudig voorbeeld. We hebben een e-mail met als onderwerp “Hoe gaat het?” Wij gebruiken een base64-decoder en kijken hoe het onderwerp van het bericht er in de broncode van de brief uit komt te zien.

Hoe is het met je? - 0JrQsNC6INC00LXQu9CwPw==

En dit zie je in de kop van de brief met alle servicetoevoegingen:

Onderwerp: =?UTF-8?B?0JrQsNC6INC00LXQu9CwPw==?=

U moet eerst de codering verwijderen =?UTF-8?, dan weet ik niet wat de symbolen betekenen B?, dan aan het einde dit ?= . Zo krijg je de zin die je zoekt. Stel je nu voor dat iemand deze brief beantwoordt. Het onderwerp van het bericht zal zijn Re: Hoe gaat het met jou?. In base64 zal deze zin er compleet anders uitzien:

Re: Hoe gaat het?UmU6INCa0LDQuiDQtNC10LvQsD8=

En hier ziet u hoe in de echte header:

Onderwerp: =?UTF-8?B?UmU6INCa0LDQuiDQtNC10LvQsD8=?=

Wat de complexiteit nog groter maakt, is het feit dat er verschillende zijn e-mailclients gebruik een andere codering in de onderwerpregel. Ik heb zowel UTF-8 als WIN-1251 gezien. Dat wil zeggen, om het onderwerp van een bericht normaal te kunnen decoderen en lezen, moet u verwerking voor decodering uitvoeren, voor het verwijderen van servicetekens. Zelfs tijdens het testproces merkte ik dat als je niet de hele tekst van het onderwerp gebruikt, maar slechts een deel ervan, de gecodeerde zoekreeks enigszins kan afwijken van wat er in het onderwerp van de brief staat. Er kunnen wijzigingen optreden als gevolg van hoofdletters/kleine letters, spaties, komma's, enz. Over het algemeen heb ik dit onderwerp niet onder de knie, omdat ik mezelf heel goed in het onderwerp moet verdiepen en veel moet schrijven diverse controles en voorwaarden. Ik had gewoon niet het geduld om alles mooi te doen, zodat het script betrouwbaar zou werken.

Uiteindelijk handelde ik anders, eenvoudiger en onhandiger, maar betrouwbaar. Stel dat u wilt voorkomen dat bepaalde correspondentie langer dan een bepaalde tijd op de server wordt bewaard. Het zou kunnen vertrouwelijke informatie. U scant bijvoorbeeld documenten die naar het postkantoor moeten worden gestuurd en u wilt dat de scans daar niet voor onbepaalde tijd worden bewaard. Stel een berichtonderwerpsjabloon in op de MFP door aan het begin de volgende regel toe te voegen: !del. Converteer het vervolgens naar base64 en voeg meer zinnen toe met Re: en Fwd: voor het geval deze brieven ergens heen kunnen worden doorgestuurd of er antwoorden kunnen worden geschreven. Het is natuurlijk onwaarschijnlijk dat iemand op de scanner zal reageren, maar misschien is dit relevant voor uw berichtonderwerp.

!delIWRlbA==
Re: !delUmU6ICFkZWw=
Fwd: !delRndkOiAhZGV's

Grep -E -R -l -I "Onderwerp:.*IWRlb.*|Onderwerp:.*RndkOiAhZGVs.*|Onderwerp:.*UmU6ICFkZWw.*""$a" >> $copydir/$box/copy-$data_full.txt

Deze regel zoekt in alle berichten die door het vorige commando tot een lijst zijn gevormd de berichtonderwerpen!del, Re: !del, Fwd: !del en kopieert de paden en bestandsnamen naar de lijst. Dan kunt u naar eigen inzicht met deze lijst werken.

Nog een paar voorbeelden van het werken met de maildatabase

Dit voorbeeld is relevant als u mailboxen gebruikt, waar absoluut alle correspondentie op uw server wordt gekopieerd. Stel dat je een doos hebt [e-mailadres beveiligd], waar alle uitgaande correspondentie wordt opgeslagen. Als er actieve correspondentie op de server is, zullen er veel brieven in de mailbox zitten en zal het zoeken met een soort imap-client lastig zijn, omdat dit ofwel langzamer kan gaan grote lijst letters, of vallen er zelfs af als gevolg van een time-out en zoeken of sorteren zal met behulp hiervan onmogelijk zijn. Dan komen ze te hulp eenvoudige scripts in de serverconsole. Laten we in deze brievenbus alle brieven zoeken die tussen 1 en 7 september 2017 zijn verzonden en deze naar een aparte brievenbus kopiëren.

Zoek /data/mail/virtueel/ [e-mailadres beveiligd]/Maildir/*/ -newerBt "01-09-2017 00:00" -en -niet -newerBt "07-09-2017 00:00" -en -type f | cpio -pdmv /data/mail/virtueel/ [e-mailadres beveiligd]/Maildir/nieuw

In wezen zijn de sleutels tot commando vinden. Ze heeft er zoveel dat ik altijd kant-en-klare ontwerpen bewaar voor alle toegepaste taken, zodat ik niet alle toetsen en mogelijkheden opnieuw hoef te onthouden.

Ook kan het handig zijn om naar de grootte van mailboxen te kijken. Sommige gebruikers hebben vele malen meer boxvolume dan alle anderen. Er zijn mensen die graag presentaties per post opslaan, archieven in delen verzenden, enz. Soms moet u handmatig de grootte van de vakken controleren om een ​​opdracht te geven om de te volle vakken te legen. Dit kan gedaan worden met een eenvoudig commando in de map met de vakken:

# du --max-diepte=1 | sorteer -n -r

De opdracht geeft de grootte van alle vakken weer en sorteert ze naarmate hun volume toeneemt, maar het volume wordt in bytes weergegeven, wat niet erg handig is. U kunt mappen alfabetisch weergeven, maar met de grootte in de gebruikelijke megabytes of gigabytes, maar zonder sortering.

# du -h --max-diepte=1

Nog handiger is het om de uitvoer rechtstreeks naar te sturen tekstbestand met de datum in de bestandsnaam, zodat u later handig kunt vergelijken met wat er gebeurde na het opschonen van de maildatabase.

# du -h --max-diepte=1 >> "dirsize_`date +"%Y-%m-%d_%H:%M"`.txt"

Hier kunt u veel verschillende manieren bedenken om de gegevens te sorteren voor een gemakkelijkere waarneming, of vervolgens automatisch de afmetingen van de dozen vergelijken. Ik heb dit niet gedaan.

Conclusie

Deelde wat ik gebruikte de laatste tijd bij het werken met mailservers. Over het algemeen - niets bijzonders. Mailservers op postfix + duiventil vereisen meestal geen frequent toezicht. Ze werken betrouwbaar en hebben geen noodzaak verhoogde aandacht. Het is voldoende om de vrije ruimte te configureren en te controleren, waarbij u periodiek de e-maildatabase opruimt, wat een reeks gewone bestanden is.

Ik raad u ook aan om op de een of andere manier een back-up van uw e-maildatabase te maken (u kunt eenvoudigweg een map met mailboxen gebruiken) en deze zo te configureren dat u in één oogopslag de dynamiek van veranderingen in de grootte van de e-maildatabase kunt evalueren. Indien gewenst kunt u een trigger configureren die op bepaalde basiswaarden reageert.

Online cursus "Linux Beheerder"

Als u wilt leren hoe u zeer beschikbare en betrouwbare systemen kunt bouwen en onderhouden, raad ik u aan kennis te maken met online cursus “Linux Beheerder” in OTUS. De cursus is niet voor beginners; voor toelating heb je wel toegang nodig basiskennis via netwerken en Linux-installatie naar de virtuele machine. De training duurt 5 maanden, waarna succesvolle afgestudeerden interviews met partners kunnen ondergaan. Test jezelf tijdens de toelatingstest en bekijk het programma voor meer details. Dmitri Vladimirovitsj, 9 september 2014 om 11:17 uur

Probleemstelling: we hebben een op Postfix gebaseerde mailserver geconfigureerd met gebruikers in MySQL en Dovecot als MDA, we moeten onze mailserver configureren als back-up MX voor individuele klanten. De situatie wordt gecompliceerd door de noodzaak om meerdere actieve mailboxen op onze mailserver te hebben, ongeacht of deze zich op de hoofdmailserver bevinden of niet. Wat is deze complexiteit en waarom is deze nodig - we zullen nu overwegen...

Een lange en gedetailleerde inleiding tot de essentie van de zaak

Waarom was dit nodig? In principe is het voldoende om de backend-optie PostfixAdmin te gebruiken " Mailserver is backup MX" en alle e-mail wordt als een uurwerk doorgestuurd voor het geselecteerde domein, aangezien het domein wordt vermeld in de optie relay_domains in de Postfix-opties.

Ik hoop dat iedereen weet waarom een ​​back-up mailserver nodig is en welke rol deze speelt in de keten van mailservers die het klantdomein bedienen? Het klassieke gebruik ervan is om een ​​domein te bedienen als de belangrijkste (back-up) mailservers om een ​​of andere reden niet beschikbaar zijn. Daarom is hij een back-up.

Het leven zou echter saai zijn als er geen problemen waren die speciale oplossingen vereisten. In sommige gevallen heeft de klant bijvoorbeeld onze mailserver nodig om mailingbrieven te verzenden namens het hoofddomein van de klant (bijvoorbeeld namens [e-mailadres beveiligd]), waarvoor onze mailserver noch back-up, noch primaire mailserver is. Om (on)begrijpelijke redenen wilde de opdrachtgever zo’n box niet maken.

In dergelijke gevallen zijn de volgende problemen mogelijk:

  • e-mail verzonden door onze server wordt niet afgeleverd lokale adressen het domein van de klant (onze server heeft het “heilige vertrouwen” dat deze uitsluitend het client.com-domein bedient, en bij het verzenden naar adressen zoals [e-mailadres beveiligd] u ontvangt de foutmelding 500 "Ontvangeradres afgewezen: gebruiker onbekend in virtuele mailboxtabel");
  • De mail van de klant komt vaak in de spammap terecht, omdat onze server niet geautoriseerd is om mail te versturen namens het domein client.com van de klant (de server staat niet vermeld als het MX-record van de klant in DNS; de server is niet opgenomen in de lijst met geautoriseerde mailservers in het SPF-record van het client.com-domein);

Om deze problemen te elimineren, moet u de volgende instellingen uitvoeren.

1. Autoriseer de mailserver in de SPF van de client

Het is voldoende om onze mailserver toe te voegen via IP (bijvoorbeeld 99.111.222.88/32) en/of via zijn domeinnaam(ourmail.server.com) in het SPF-domeinrecord van de klant, zoals hieronder weergegeven:

V=spf1 ip4:99.111.222.88/32 … een mx … include:ourmail.server.com … ~all

2. Wijs de mailserver toe als Backup MX voor het clientdomein client.com

Houd er rekening mee dat de belasting op onze mailserver vele malen kan toenemen, omdat de back-up mailserver gedwongen wordt het hele domein van de klant te bedienen als de primaire mailserver van de klant om een ​​of andere reden niet beschikbaar is. Ook kunnen we verzoeken ontvangen die zijn afgewezen door de hoofdmailserver en uiteraard spam. Waar zouden we zijn zonder hem?

Om onze server op te geven als back-up voor het client.com-domein, moet u: DNS-records geef voor het client.com-domein een MX-record op met een gewicht dat hoger (groter) is dan het gewicht van de hoofdmailserver van de client:

Klant.com. MX 10 mail.client.com; client-mailserver client.com. MX 50 onzemail.server.com; onze back-up mailserver

3. Markeer het domein van de klant in PostfixAdmin als back-up

Figuur 1 - een back-up MX-domein instellen in postfixadmin

Vink in de domeininstellingen het selectievakje 'Mailserver is backup MX' aan. Vanaf dit moment zal onze server alle e-mail van het client.com-domein ontvangen en doorsturen (relay).

4. Configureer een transport om e-mail door te sturen naar de hoofdserver van de client, met uitzonderingen

Zoals hierboven vermeld bedient onze mailserver zelf ook het client.com-domein en beschikt over meerdere lokaal aangemaakte mailboxen, wat leidt tot problemen met transport en mail die rechtstreeks door onze mailserver wordt geïnitieerd (bijvoorbeeld verzonden vanuit een mailbox [e-mailadres beveiligd]) en bedoeld voor het client.com-domein (bijvoorbeeld for [e-mailadres beveiligd]) wordt niet verzonden. Om dit te voorkomen, moet u het postfix-transport als volgt configureren...

Bestand maken /etc/postfix/transport en voeg daar de nodige regels aan toe voor het doorgeven van e-mail voor domeinen waarvoor onze mailserver een back-up is. Specificeer in het bijzonder ons virtueel transport voor de mailboxen die rechtstreeks op onze mailserver zijn aangemaakt virtueel:, voor alle anderen: geef de hoofdmailserver van de client aan tussen rechthoekige haakjes of het domein ervan, maar zonder haakjes:

Root@mailserver:/# vim /etc/postfix/transport [e-mailadres beveiligd] virtueel: [e-mailadres beveiligd] virtueel: [e-mailadres beveiligd] virtueel: [e-mailadres beveiligd] virtueel: client.com smtp: voorbeeld.com smtp:voorbeeld.com

Opmerking: let op de rechthoekige haakjes - dit is een verbod voor de mailserver om te zoeken naar een MX-record voor dit domein, of met andere woorden - een expliciete aanduiding van de mailserver waarnaar we mail willen sturen. Meer informatie vindt u uiteraard in officiële documentatie- man 5 vervoer

Links opgegeven bestand hash en voer het in postfix:

Root@mailserver:/# postmap /etc/postfix/transport root@mailserver:/# vim /etc/postfix/main.cf … transport_maps = hash:/etc/postfix/transport …

Nadat u wijzigingen heeft aangebracht, moet u postfix opnieuw opstarten.

Root@mailserver:/# service postfix herladen

Als gevolg hiervan wordt alle e-mail die aan deze domeinen is geadresseerd, doorgestuurd naar de hoofdmailserver, met uitzondering van de mailboxen die rechtstreeks op onze server worden aangemaakt en onderhouden. Nu doet onze server uitstekend werk bij het verzenden van abonnementen naar klanten, en verzamelt e-mail in een wachtrij en stuurt deze door naar de hoofdmailserver als deze een tijdje plotseling 'valt' en dan 'stijgt'.

Opmerkingen

Reacties zijn uitgeschakeld, sorry

Nieuw op de site

het opzetten van een mailserver als backup (backup MX) of het doorsturen van mail voor een klantdomein

We moeten onze server configureren als een back-up Backup MX voor individuele clients. De situatie wordt gecompliceerd door de noodzaak om meerdere actieve mailboxen op onze server te hebben, ongeacht of deze zich op de hoofdmailserver bevinden of niet. Waarom was dit nodig?