[linux] Re: Carbon copy procmail

[Kees Theunissen]

On Thu, 10 Mar 2005, Richard de Vries wrote:

>> Je kan met een "c" vlag (continue) aangeven dat verdere
>
>Jaja, continue, ik dacht copy.

Ik heb niet nagezocht welke term de manpage gebruikt. "Continue"
was mijn eerste associatie. Maar misschien is "copy" een term die
beter omschrijft wat er gebeurt.

>>  :0
>>  * ^TO_(emailadres|anderadres|...|laatsteadres)
>>  {
>>    :0c:
>>    * ^TO_emailadres
>>    usermailbox
>>
>>    :0c:
>>    * ^TO_anderadres
>>    anderemailbox
>>
>>    ...
>>
>>    :0:
>>    * ^TO_laatsteadres
>>    laatstemailbox
>>
>>    :0
>>    /dev/null
>>  }
>
>Dit snap ik niet.
>Er zal toch altijd een user zijn anders zou het in mijn huidige situatie
>die al jaren werkt ook al fout zijn gegaan ?

Ik weet niet wat je al die jaren gedaan hebt. Ik kan wel speculeren.
Als je mail afgeleverd hebt naar mailboxen van andere gebruikers dan
moet je procmail process met root rechten gedraaid hebben, anders kan
dat process niet in andermans mailboxen geschreven hebben.
Ik neem dus als eerste aan dat het script draait met root rechten.

Tot nu toe heb je steeds berichten afgeleverd via een recipe in één
mailbox. Alles wat aan het eind van je script nog niet was afgeleverd
ging de mailbox van root in (waarschijnlijk /var/spool/mail/root).
Misschien heb je in je .procmailrc als laatste recipe een "catch all"
die alle nog niet afgeleverde mail opvangt en in een user mailbox stopt.
Hoe dan ook: er is een plek waar alle mail terecht komt die niet
expliciet ergens anders gedropt wordt. Laten we die plek maar "inbox"
noemen. Op die plek, inbox, zal je nu een heleboel mail extra gaan
krijgen als je niet uitkijkt.
Want nu ga je een aantal keren zeggen: maak maar een kopietje voor een
bepaalde mailbox en kijk met het origineel of het ook nog ergens anders
heen moet. Meestal zal het nergens anders meer heen hoeven. En dan
verdwijnt dat "origineel" in die genoemde inbox, want het was immers nog
niet afgeleverd (de _copie_ was afgeleverd). Meestal zal dat om mail gaan
die je niet in die inbox wilt hebben. Je moet nu dus iets gaan verzinnen
om selectief de "originelen" weg te mikken waarvan je al een of meerdere
copietjes hebt afgeleverd.

Dat deed ik dus met:

  :0
  * ^TO_(emailadres|anderadres|...|laatsteadres)
  {

    ...

  }

Met "^TO_(emailadres|anderadres|...|laatsteadres)" selecteer je
alle mail voor "emailadres" of voor "anderadres" of voor ....
of voor "laatsteadres" of voor elke willekeurige combinatie van
meerdere van deze adressen.
Dat zijn de berichten die je mogelijk in meerdere mailboxen
moet stoppen. Daarnaast heb je waarschijnlijk ook mail die je niet
hoeft te testen op meerdere geadresseerden en die wordt hier ook
niet geselecteerd.

Terug naar de mail die mogelijk wel naar meerder mailboxen moet.
Binnen de accolades loop je dan een voor een de betreffende
adressen nog eens na en je levert indien nodig een copietje af.
Bij het laatste recipe hoef je geen copie te maken daar kan je
zonodig het origineel afleveren.
Als je het origineel dan nog over houdt (dat is altijd behalve
in het geval dat "laatsteadres" bij de geadresseerden zat) dan
wordt dat origineel in de grote bittenbak gegooid met:

 :0
 /dev/null

als laatste recipe binnen de accolades.

Merk op dat in de regel "^TO_(emailadres|anderadres|...|laatsteadres)"
alle adressen genoemd staan die binnen de accolades ook nog eens ieder
hun eigen recipe krijgen. Als je dus ooit een adres wilt toevoegen,
weghalen of veranderen dan zal je dat op twee plekken moeten doen.
Dat lijkt nodeloos ingewikkeld maar zo maak je eerst een selectie
van de hele groep en dan ga je met geneste recipes (binnen de accolades)
alleen die mail bezorgen die binnen de selectie viel. Zo voorkom je
dat je met het laatste recipe mogelijk de verkeerde mailtjes
weg gooit.
In plaats van die geneste recipes had ik ook bij het weg mikken
op het laatst wat selectiever kunnen zijn:

 :0
 * ^TO_(emailadres|anderadres|...|laatsteadres)
 /dev/null

Zo gooi je dus ook alleen maar mail weg waarvan je weet dat je al een
copie hebt afgeleverd. De volgorde van de recipes is natuurlijk heel
belangrijk. Ook hier moet je toekomstige wijzigingen steeds op twee
plekken doorvoeren. Voor mijn gevoel heb je bij geneste recipes minder
kans om dan die tweede wijziging te vergeten, omdat de receipes
duidelijker gegroepeerd zijn.

Dit soort lastig te onderhouden constructies zijn niet fraai want je
vergroot de kans om later fouten te maken. Maar ik had al gezegd dat
procmail niet het beste tooltje is voor deze job.

Groeten,

Kees.

-- 
Kees Theunissen
F.O.M.-Instituut voor Plasmafysica "Rijnhuizen", Nieuwegein
E-mail: theuniss op rijnh.nl,     Tel: 030-6096724,     Fax: 030-6031204