Archiwa tagu: wirtualne konta

Weryfikacja nadawcy maila część 1.

konfiguracja usług, , ,

Podczas dotychczasowych opisów konfiguracji Exima umknęła mi kwestia weryfikacji nadawcy, czy nadawca jest taki sam jak użytkownik, który się zautoryzował poprzez SMTP AUTH. Na tą sytuację zwrócił mi uwagę Adrian H. Dzięki :)

Przykładowo, mamy konto pocztowe zbieram_spam@kolekcja.mejor.pl , w programie pocztowym konfigurujemy w połączenie do serwera SMTP użytkownika zbieram_spam@kolekcja.mejor.pl , natomiast w ustawieniach konta możemy wprowadzić: prezes_firmy@kolekcja.mejor.pl . Czyli w mailu pojawi nam się From:  prezes_firmy@kolekcja.mejor.pl pomimo tego, że nie mamy prawa korzystać z tego konta.

Musimy więc porównać, czy sender, czyli nadawca jest taki sam jak użytkownik, który odmeldował nam się loginem i hasłem. Zatem w acl_check_data (czyli tak naprawdę w acl_smtp_data) , gdzieś blisko początku, dodajemy:

deny     authenticated  = *
condition      = ${if eq {$authenticated_id}{${lc:$sender_address}}{no}{yes}}
message         = rejected: Nieprawidłowy nadawca.

Tutaj pojawił mi się mały dylemat, pisząc poprzednie teksty, przyjąłem odruchowo, że alias do konta jest aliasem służącym tylko do odbierania poczty. Pisząc obrazowo, jest konto zbieram_spam@kolekcja.mejor.pl do którego zakładamy aliasy: uwielbiam_ICIC@kolekcja.mejor.pl oraz icic_to_miedzynarodowi_spamerzy@kolekcja.mejor.pl

to mail przychodzący pod dowolny w/w adres wyląduję w jednym i tym samym maildirze. Natomiast pocztę można wysyłać jedynie jako zbieram_spam@kolekcja.mejor.pl . Natomiast Adrian zasugerował, że zbieracz_spamu mógłby także chcieć wysłać maila jako icic_to_miedzynarodowi_spamerzy@kolekcja.mejor.pl . A tego powyższy wpis nie dopuszcza.

Jak to zrobić jest w drugiej części.

Exim i aliasy z bazy postgresowej

konfiguracja usług, linux, , ,

Aliasy trzymam w bardzo prostej tabelce:

CREATE TABLE aliasy
(
id serial NOT NULL,
alias text NOT NULL DEFAULT ”::text,
destination text NOT NULL DEFAULT ”::text,
CONSTRAINT aliasy_pkey PRIMARY KEY (id)
);

CREATE UNIQUE INDEX ind_alias
ON aliasy
USING btree
(alias);

CREATE TRIGGER cleanup_aliases
BEFORE INSERT OR UPDATE
ON aliasy
FOR EACH ROW
EXECUTE PROCEDURE cleanup_aliases();

CREATE OR REPLACE FUNCTION cleanup_aliases()
RETURNS „trigger” AS
$BODY$
DECLARE
BEGIN
NEW.alias := trim(both FROM lower(NEW.alias));
NEW.destination := trim(both FROM lower(NEW.destination));
RETURN NEW;
END;
$BODY$
LANGUAGE 'plpgsql’ VOLATILE;

Do tego jest trigger mający na celu zapisać w bazie dane małymi literami z obciętymi spacjami na początku oraz końcu. Ten trigger jest zapożyczony z blogu depesza.

Sam ruter w eximie wygląda następująco:

aliasy_postgres:
driver = redirect
allow_fail
allow_defer
data = ${lookup pgsql{ SELECT destination FROM aliasy where alias = (’${quote_pgsql:$local_part}@${quote_pgsql:$domain}’) }}

Exim + postgresql

konfiguracja usług, , , , ,

Nadeszła chwila, kiedy to unixowe konta nie wystarczają do obsługi poczty. Witajcie wirtualni userzy.

Dlaczego postgres? Ponieważ bardzo nie lubię mysqla.

Podczas migracji korzystałem z różnych opisów dostępnych w sieci, wiele informacji (oraz trigerów :)  ) zaczerpnąłem ze strony depesza oraz ze strony Baseciqa . Okazało się jednak, że w powyższych opisach,  oraz w wielu innych jakie google podsuwały, brakowało kilku kluczowych elementów aby exim działał tak jak powinien działać serwer pocztowy. Tym „drobiazgiem” była przede wszystkim nieomówiona autoryzacja użytkowników wysyłających pocztę. Silnie podpierając się stroną ( http://devel.reinikainen.net/attachments/Exim/configure ) uruchomiłem możliwość wysyłania poczty wirtualnym użytkownikom.

Uff, następuje pierwsza próba wysłania maila. I zonk. Okazuje się, że exim dokleja swój primary hostname do adresu mailowego nadawcy. Czyli miałem nadawce takiego:

„user@wirtualna.domena.tld@moj.komputer.tld”

Tutaj wszystko zamykało się w jednej linijce:

control       = submission/sender_retain

Kolejna próba.. I? Pełny sukces! Zadziałało!

Kolejnym etapem będzie uruchomienie aliasów.