PROCMAILRC(5) | File Formats Manual | PROCMAILRC(5) |
procmailrc - plik rc procmaila
$HOME/.procmailrc
Szybką orientację w temacie można uzyskać, czytając UWAGI umieszczone na końcu strony podręcznika procmail(1).
Plik rc składa się z przypisań zmiennych środowiskowych (niektóre z nich mają specjalne znaczenie dla procmaila) i reguł. W najprostszej postaci, reguły są po prostu jednoliniowymi wyrażeniami regularnymi, które są poszukiwane w nagłówkach przychodzącej poczty. Pierwsza reguła, która zostanie dopasowana, jest używana do określenia, gdzie dany list ma pójść (zwykle do pliku). Jeśli przetwarzanie dojdzie do końca pliku rc, procmail dostarczy pocztę do $DEFAULT.
Istnieją dwa rodzaje reguł: dostarczające i niedostarczające. Jeśli dopasowana zostanie reguła dostarczająca, procmail zakłada, że poczta (jak się można domyślić) jest dostarczona i zakończy przetwarzanie pliku rc po wykonaniu linii akcji reguły. Jeśli dopasowana zostanie reguła niedostarczająca, to przetwarzanie pliku rc będzie kontynuowane nawet po wykonaniu akcji tej reguły.
Reguły dostarczające są tymi, które powodują zapis nagłówka lub ciała listu do pliku, jego zaabsorbowanie przez program lub przekazanie (forwardowanie) do innego adresu pocztowego.
Reguły niedostarczające to te, które łapią wyjście programu lub filtru z powrotem do procmaila, lub te, które rozpoczynają zagnieżdżony blok.
Można powiedzieć procmailowi, by traktował regułę dostarczającą jako niedostarczającą poprzez przekazanie takiej regule flagi "c". Spowoduje to, że procmail wygeneruje kopię listu (carbon copy), dostarczając go regule i kontynuując przetwarzanie pliku rc.
Używając dowolnej liczby reguł, można posortować pocztę wprost do określonych folderów pocztowych. Należy pamiętać jednak, że poczta może wpływać do tych folderów w tym samym momencie (jeśli kilka procmaili działa naraz, co nie jest nieprawdopodobne przy dużej ilości poczty). Aby upewnić się, że nie narobi to bałaganu, zalecane jest robienie właściwego użytku z plików blokujących.
Inicjacje zmiennych środowiskowych i reguły mogą być swobodnie przeplatane w pliku rc. Jeśli zmienna środowiskowa ma dla procmaila specjalne znaczenie, zostanie użyta odpowiednio w momencie przetwarzania. (np. można zmienić katalog bieżący, kiedy tylko jest taka potrzeba, przez podanie nowego MAILDIR, zamienić pliki blokujące przez podanie nowego LOCKFILE, zmienić umask, itd., możliwości jest nieskończenie wiele :-).
Inicjacje i podstawienia tych zmiennych środowiskowych są obsługiwane dokładnie jak w sh(1) (włączając w to wszystkie możliwe cytowania i sekwencje specjalne) i dodatkowo: spacje dookoła znaku "=" są ignorowane, a każda zmienna nie zawierająca końcowego "=" zostanie usunięta ze środowiska. Każdy program w odwrotnych apostrofach, uruchomiony przez procmail, będzie miał przekazany cały list na swoim wejściu (stdin).
Słowo zaczynające się od # wraz z wszystkimi znakami występującymi po nim aż do znaku nowej linii jest ignorowane. Nie dotyczy to linii warunkowych, które nie mogą być komentowane.
Linia zaczynająca się od ":" oznacza początek reguły. Ma następujący format:
:0 [flags] [ : [locallockfile] ] <zero or more conditions (one per line)> <exactly one action line>
Warunki zaczynają się od "*" i wszystko, co następuje po tym znaku, jest przekazywane niezmienione wewnętrznemu egrepowi, z wyjątkiem początkowych i końcowych białych spacji. Wyrażenia regularne są całkowicie kompatybilne z normalnymi wyrażeniami regularnymi egrep(1). Zobacz także Rozszerzone wyrażenia regularne.
Warunki są logicznie koniugowane; jeżeli nie ma warunków, wynik jest domyślnie prawdziwy.
Flagi mogą być dowolnymi z
następujących:
Istnieją pewne warunki specjalne, których
można użyć, a które nie są w pełni
wyrażeniami regularnymi. Aby je wybrać, warunek musi
zaczynać się od:
Jeśli umieści się drugi (kończący) ":" w pierwszej linii reguły, to procmail użyje lokalnego pliku blokującego (locallockfile; tylko dla tej reguły). Opcjonalnie można podać nazwę pliku, który będzie użyty; jednak jeśli się tego nie zrobi, procmail użyje nazwy pliku celu (lub nazwy pliku następującej po pierwszym ">>") i dopisze do niej $LOCKEXT.
Linia akcji może zaczynać się od
następujących znaków:
Wszystko inne będzie uznawane za nazwę skrzynki pocztowej (zarówno nazwę pliku lub katalogu, bezwzględną lub względną w stosunku do bieżącego katalogu (zobacz opis zmiennej MAILDIR)). Jeśli jest to (możliwe że jeszcze nieistniejąca) nazwa pliku, poczta zostanie do niego doklejona.
Jeśli jest to katalog, poczta zostanie dostarczona do nowo
utworzonego, unikatowego pliku o nazwie $MSGPREFIX* w podanym
katalogu. Jeśli nazwa skrzynki pocztowej kończy się
"/.", to katalog ten jest uznawany za folder MH, tj. procmail
użyje następnego numeru, który będzie
dostępny. Jeśli nazwa skrzynki pocztowej kończy
się znakiem "/", to ten katalog jest uznawany za folder
maildir, tj. procmail zapisze pocztę w pliku w podkatalogu o nazwie
"tmp", a następnie przeniesie go do podkatalogu o nazwie
"new". Jeśli skrzynka pocztowa jest podana jako folder MH
lub maildir, procmail utworzy wymagane katalogi, jeśli nie
istnieją, zamiast traktować skrzynkę pocztową
jako nieistniejącą. Gdy procmail dostarcza do
katalogów, można podać wiele katalogów, do
których należy dostarczyć (procmail dostarczy
pocztę, używając twardych dowiązań).
Inne czyszczone lub preustawiane zmienne środowiskowe to IFS, ENV i PWD.
Z powodów bezpieczeństwa podczas startu procmail
wyrzuci wszystkie zmienne środowiskowe, co do których ma
podejrzenia, że mogą wpływać na działanie
dynamicznego konsolidatora (ld.so(8)).
Zanim zgubisz się w mętliku zmiennych
środowiskowych, pamiętaj że wszystkie one mają
sensowne wartości domyślne.
Następujące żetony rozpoznawane są
zarówno przez wewnętrzny egrep procmaila, jak i przez
standardowy egrep(1) (proszę być świadomym tego,
że niektóre implementacje egrepa zawierają
niestandardowe rozszerzenia, w szczególności operator
powtarzania { nie jest obsługiwany przez wewnętrznego
egrepa procmaila):
Były to tylko przykłady, oczywiście można używać również bardziej złożonych kombinacji.
Następujące znaczenia żetonów
są rozszerzeniami procmaila:
Patrz strona podręcznika procmailex(5).
Kontynuowane linie w linii akcji, która określa program, muszą zawsze kończyć się odwrotnym ukośnikiem, nawet jeśli używana powłoka nie potrzebuje lub nie chce odwrotnego ukośnika do wskazania kontynuacji. Jest tak z powodu dwustopniowego procesu przetwarzania (najpierw procmail, potem powłoka (lub nie, zależnie od SHELLMETAS)).
Nie wstawia komentarzy w regule w liniach warunkowych wyrażeń regularnych, linie te są przekazywane wewnętrznemu egrepowi wprost (z wyjątkiem odwrotnych ukośników kontynuacji znajdujących się na końcu linii).
Początkowe białe spacje w kontynuowanych wyrażeniach regularnych są zazwyczaj ignorowane (więc linie mogą być wcięte), lecz nie jest tak w kontynuowanych wyrażeniach warunkowych, które są odczytywane według reguł podstawiania sh(1) wewnątrz podwójnych cudzysłowów.
Uwaga na deadlocki podczas wykonywania niezdrowych rzeczy jak przekazywanie poczty na swoje własne konto. Deadlocki można złamać przez właściwe użycie LOCKTIMEOUT.
Wszelkie domyślne wartości, których procmail używa dla zmiennych środowiskowych zawsze przeciążą te, które były wcześniej zdefiniowane. Aby naprawdę przeciążyć wartości domyślne, należy je albo wstawić do pliku rc, albo wypisać w linii poleceń jako argumenty.
Plik /etc/procmailrc nie może zmienić ustawienia zmiennej PATH widzianej później przez pliki rc użytkowników — wartość tej zmiennej jest przywracana, gdy procmail kończy przetwarzanie pliku /etc/procmailrc. W przyszłości należy się spodziewać ulepszenia tego zachowania, jednakże obecnie jedynym rozwiązaniem jest przekompilowanie procmaila z żądaną wartością tej zmiennej.
Zmienne środowiskowe, ustawiane wewnątrz interpretowanej przez powłokę części akcji reguły "|", nie zachowają swoich wartości po zakończeniu reguły, gdyż są ustawiane w podpowłoce procmaila. Aby upewnić się, że wartość zostanie zachowana, należy dokonać przypisania przed początkowym znakiem "|" reguły, tak że może przechwycić stdout programu.
Jeśli w regule dostarczającej podana zostanie tylko
flaga "h" lub "b" i reguła ta zostanie
dopasowana, to jeżeli nie użyto flagi "c",
ciało listu lub (odpowiednio) jego nagłówek
zostaną utracone.
procmail(1), procmailsc(5), procmailex(5), sh(1), csh(1), mail(1), mailx(1), uucp(1), aliases(5), sendmail(8), egrep(1), regexp(5), grep(1), biff(1), comsat(8), lockfile(1), formail(1)
Jedyne podstawienia zmiennych środowiskowych, które mogą być obsługiwane przez samego procmaila są typu $nazwa, ${nazwa}, ${nazwa:-tekst}, ${nazwa:+tekst}, ${nazwa-tekst}, ${nazwa+tekst}, $\nazwa, $#, $n, $$, $?, $_, $- i $=; gdzie $\nazwa zostanie zastąpione przez nazwa z zacytowanymi wszystkimi znakami mającymi specjalne znaczenie w wyrażeniach regularnych; $_ będzie zastąpione nazwą bieżącego pliku rc, $- przez $LASTFOLDER, a $= będzie zawierać punktację (score) ostatniej reguły. Co więcej znaki spacji nigdy nie będą rozdzielać wyniku podstawiania $\nazwa. Gdy użyte są opcje -a lub -m to "$@" (cudzysłowy są wymagane) rozwinie się do podanych argumentów. Jednakże "$@" będzie rozwijany tylko wtedy, gdy jest używany na liście argumentów programu, i tylko jedno wystąpienie tej zmiennej będzie rozwijane.
Niecytowanie ekspansje zmiennych przeprowadzane przez procmail są zawsze dzielone na spacjach, tabulatorach i znakach nowej linii; zmienna IFS nie jest wewnętrznie używana.
Procmail nie wspiera rozwijania "~".
Bufor linii o długości $LINEBUF jest używany podczas przetwarzania pliku rc; wszystkie ekspansje, które nie mieszczą się w tym limicie długości są obcinane i ustawiana jest zmienna PROCMAIL_OVERFLOW. Jeśli zbyt długa linia jest linią warunku lub akcji, to reguła zawierająca taki warunek lub akcję jest uznawana za zakończoną niepowodzeniem, a procmail kontynuować będzie przetwarzanie kolejnych reguł. Jeśli linia taka występuje w przypisaniu zmiennej lub linii rozpoczynającej, to procmail przerwie przetwarzanie pliku rc.
Jeśli globalny plik blokujący ma ścieżkę relatywną, a bieżący katalog nie jest taki sam, jak wtedy, gdy globalny plik blokujący został utworzony, to ten globalny plik blokujący nie zostanie usunięty, jeśli procmail zakończy w tym momencie działanie (tak więc: należy używać ścieżek absolutnych dla globalnych plików blokujących).
Jeśli plik rc ma ścieżkę względną, to kiedy ten plik jest otwierany po raz pierwszy, to MAILDIR zawiera ścieżkę względną. Jeśli w którymś momencie procmail zostanie poinstruowany, żeby się sklonował, a bieżący katalog roboczy się zmienił od czasu otwarcia pliku rc, to procmail nie będzie w stanie się sklonować (lekarstwo: używanie ścieżek bezwzględnych do odwołań do plików rc lub upewnienie się, że MAILDIR zawiera ścieżkę bezwzględną przed otwarciem pliku rc).
Lokalny plik blokujący reguły, który zaznacza początek zagnieżdżonego bloku, nie działa tak, jak by się tego oczekiwało.
Gdy przechwytuje się standardowe wejście z reguły do zmiennej środowiskowej, to zostanie obcięty dokładnie jeden, kończący znak nowej linii.
Niektóre nieoptymalne i nieoczywiste wyrażenia
regularne ustawiają niepoprawną wartość zmiennej
MATCH. Takie wyrażenie regularne można poprawić,
usuwając jeden lub więcej niepotrzebnych operatorów
"*", "+" lub "?" znajdujących
się po lewej stronie tokena \/.
Jeśli wyrażenie regularne zawiera "^TO_", to zostanie zastąpione przez "(^((Original-)?(Resent-)?(To |Cc |Bcc) |(X-Envelope |Apparently(-Resent)?)-To) :(.*[^-a-zA-Z0-9_.])?)", co powinno złapać wszystkie specyfikacje celu zawierające określony adres.
Jeśli wyrażenie regularne zawiera "^TO", to zostanie zastąpione przez "(^((Original-)?(Resent-)?(To |Cc |Bcc) |(X-Envelope |Apparently(-Resent)?)-To) :(.*[^a-zA-Z])?)", co powinno złapać wszystkie specyfikacje celu zawierające określone słowo.
Jeśli wyrażenie regularne zawiera "^FROM_DAEMON", to zostanie zastąpione przez "(^(Mailing-List : |Precedence :.*(junk |bulk |list) |To : Multiple recipients of |(((Resent-)?(From |Sender) |X-Envelope-From) : |>?From )([^>]*[^(.%@a-z0-9])?(Post(ma?(st(e?r)? |n) |office) |(send)?Mail(er)? |daemon |m(mdf |ajordomo) |n?uucp |LIST(SERV 'u' |proc) |NETSERV |o(wner |ps) |r(e(quest |sponse) |oot) |b(ounce 'u' |bs\.smtp) |echo |mirror |s(erv(ices? |er) |mtp(error)? |ystem) |A(dmin(istrator)? |MMGR |utoanswer))(([^).! :a-z0-9][-_a-z0-9]*)?[%@>\t ][^<)]*(\(.*\).*)?)?$([^>] |$)))", co powinno złapać maile pochodzące od większości demonów (jak się podoba to wyrażenie regularne? :-)
Jeśli wyrażenie regularne zawiera "^FROM_MAILER", to zostanie zastąpione przez "(^(((Resent-)?(From |Sender) |X-Envelope-From) : |>?From )([^>]*[^(.%@a-z0-9])?(Post(ma(st(er)? |n) |office) |(send)?Mail(er)? |daemon |mmdf |n?uucp |ops |r(esponse |oot) |(bbs\.)?smtp(error)? |s(erv(ices? |er) |ystem) |A(dmin(istrator)? |MMGR))(([^).! :a-z0-9][-_a-z0-9]*)?[%@>\t ][^<)]*(\(.*\).*)?)?$([^>] |$))" (uproszczona wersja "^FROM_DAEMON"), co powinno złapać maile pochodzące od większości demonów pocztowych.
Podczas przypisywania wartości logicznych zmiennym takim jak VERBOSE, DELIVERED czy COMSAT, procmail przyjmuje jako prawdziwy napis zaczynający się od: cyfry różnej od zera, "on", "y", "t" lub "e". Fałsz jest każdym napisem zaczynającym się od: cyfry zero, "off", "n", "f" lub "d".
Jeśli linia akcji reguły określa program, to pojedyncza para znaków odwrotny-ukośnik+nowa-linia w niej występująca zostanie przekształcona w nową linię, pod warunkiem, że linia nie zawiera innych żadnych znaków.
Silnik wyrażeń regularnych wbudowany w procmaila nie
obsługuje nazwanych klas znaków (np. [:alnum:]).
Ponieważ niecytowane początkowe białe spacje są ogólnie ignorowane w plikach rc, można zastosować takie wcięcia linii, jakie nam odpowiadają.
Początkowy znak "|" w linii akcji wskazującej program lub filtr, jest obcinane przed sprawdzeniem $SHELLMETAS.
Pliki włączane dyrektywą INCLUDERC zawierające tylko przypisania wartości zmiennym środowiskowym mogą być dzielone z sh(1).
Nie ma żadnych gwarancji, że bieżące zachowanie przypisań zmiennych INCLUDERC i SWITCHRC w linii poleceń nie zostanie zmienione. Zostało już raz zmienione w przeszłości i może być zmienione ponownie lub nawet usunięte w przyszłych wersjach.
W celu naprawdę skomplikowanego przetwarzania można nawet rozważyć rekurencyjne wywoływanie procmaila.
W bardzo starych wersjach procmaila zamiast ":0"
rozpoczynającego regułę trzeba było
używać ":n", gdzie n oznaczało liczbę
warunków w regule.
Stephen R. van den Berg
<srb@cuci.nl>
Philip A. Guenther
<guenther@sendmail.com>
Autorami polskiego tłumaczenia niniejszej strony podręcznika są: Przemek Borys <pborys@dione.ids.pl>, Robert Luberda <robert@debian.org> i Michał Kułach <michal.kulach@gmail.com>
Niniejsze tłumaczenie jest wolną dokumentacją. Bliższe informacje o warunkach licencji można uzyskać zapoznając się z GNU General Public License w wersji 3 lub nowszej. Nie przyjmuje się ŻADNEJ ODPOWIEDZIALNOŚCI.
Błędy w tłumaczeniu strony podręcznika prosimy zgłaszać na adres manpages-pl-list@lists.sourceforge.net.
2001/08/04 | BuGless |