Komentarze i odpowiedzi, posortowane dla odmiany chronologicznie do strony:
postfix i port 587tkniaz
2009-11-21 23:09:36
przeniesione regulki
Czasem moze byc przyjemniej przeniesc smtpd_*_restrictions z master.cf do main.cf (ale zakladam ze to sprawa "estetyki" :)):
master.cf:
#v+
submission inet n - n - - smtpd
[...]
-o smtpd_recipient_restrictions = $submission_recipient_restrictions
[...]
#v-
main.cf
#v+
submission_recipient_restrictions =
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
permit_sasl_authenticated,
reject
#v-
master.cf:
#v+
submission inet n - n - - smtpd
[...]
-o smtpd_recipient_restrictions = $submission_recipient_restrictions
[...]
#v-
main.cf
#v+
submission_recipient_restrictions =
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
permit_sasl_authenticated,
reject
#v-
Madej
2009-11-25 01:06:01
Uwaga dla tych co mają chroot (np. domyślnie w debianie)
Po copy-paste pamiętajcie, by zmienić środkowe 'n' na '-' w pierwszej wstawionej linii.
Inaczej mówiąc trzeba mieć to samo co w linijce smtp.
Inaczej mówiąc trzeba mieć to samo co w linijce smtp.
ananiash
2009-12-02 08:50:45
Dlaczego kretyński?
Dlaczego "Da się, powinno nawet działać, ale pomysł jest moim zdaniem kretyński."?
Odpowiedź Lemata:
Jeżeli chodzi o taką regułę na serwerze pocztowym to patrz wypowiedź obok. Jeżeli chodzi o taką regułę na ruterze to w przypadku zombie wewnątrz sieci lokalnej ona wypuszcza w świat połączenia, do których by normalnie nie doszło - obciążając tym łącze.
W całej tej szopce chodzi o to aby kontrolować spam a nie aby odpierdalać obejścia dzięki którym wszystko teoretycznie działa, ale spam jak płynął tak płynie.
W całej tej szopce chodzi o to aby kontrolować spam a nie aby odpierdalać obejścia dzięki którym wszystko teoretycznie działa, ale spam jak płynął tak płynie.
fabio
2009-12-02 09:24:22
iptables
iptables -t nat -A PREROUTING -p tcp --dport 587 -i eth0 -j REDIRECT --to-ports 25
gdzie eth0 jest oczywiste.
Podaj może choć jakiś powód dla którego ten pomysł jest "kretyński"
gdzie eth0 jest oczywiste.
Podaj może choć jakiś powód dla którego ten pomysł jest "kretyński"
Odpowiedź Lemata:
bo funkcjonalność (reguły smtpd_*_restrictions dla portów 25 i 587) się różnią.
o
2009-12-03 16:36:59
problem z portem 587 i postfix
Wpisałem jak powyzej, ale postfix nie nasluchuje na porcie 587
587/tcp closed submission
W iptables wpuszczam wiec w czym problem?
587/tcp closed submission
W iptables wpuszczam wiec w czym problem?
Odpowiedź Lemata:
pl.comp.mail.mta - zadaj tam pytanie dostarczając master.cf
Maciuś
2009-12-04 21:58:36
W przypadku e-maili wysyłanych od siebie do siebie
Jest błąd: User unknown in virtual alias table
Pozdrawiam
Pozdrawiam
Odpowiedź Lemata:
coś spieprzyłeś.
Wojtek
2009-12-05 08:09:03
Postfix w debianie
Wystarczy odhaszować linijkę:
587 inet n - n - - smtpd -o smtpd_enforce_tls=no -o smtpd_sasl_auth_enable=yes
aby miec juz podstawowo dzialajace smtp via 587.
587 inet n - n - - smtpd -o smtpd_enforce_tls=no -o smtpd_sasl_auth_enable=yes
aby miec juz podstawowo dzialajace smtp via 587.
Odpowiedź Lemata:
no właśnie - to jest złe, bo rola portu 587 jest inna.
Jacek
2009-12-09 20:31:46
nie działa :(
Niestety u mnie to nie działa. Klient ma neostradę łaczy się z moim serwerem skonfigurowanym według twoich zaleceń na 587 ale niestety prosi go o podanie użytkownika i hasła :( . Na razie sobie poradziłem przekierowaniem na routerze 587 na 25 ale wiem , że nie jest to dobre rozwiązanie. Na serwerze mam skonfigurowanego debiana według perfect debian setup ( how to forge ), oczywiście saslauth działa
Odpowiedź Lemata:
a jakbyś zajrzał w logi to co by się stało?
boski marian lamon co się zowie
2010-01-06 01:17:50
587 przyczyn
szacun za wyłożoną tutaj wiedzę
ja mam z kolei inny problem, w uzbrojonym po zęby postfixie (confixx 3.3.5, ruble, earl'grey, spam'esesman ;P) zaaplikowałem wpisy, które podałeś, wszystko ładnie śmiga na porcie 25 i... na 587... z jednym wyjątkiem, łącząc się z kontem przez 587 połączenie zostaje ustanowione, kiedy poczta zostaje wysłana na konto w obrębie serwera po chwili dostaję zwrotkę: : User unknown in virtual alias table... a jak wół w tej tablicy wszystko wypisane, zwrotki nie dostaję kiedy poczta wychodzi na inny serwer
i jeszcze kwestia z innej bajki, mam to życiowe szczęście mieć joomlę na serwerze i paskuda po wszystkich możliwych sztuczkach z konfigiem nie chce wysyłać maili z formularza kontaktowego (standardowy komponent), w logach postfixa nawet przy użyciu smtp cisza, inne mailery w komponentach nie robią problemów... czy postfix macza w tym palce?
ja mam z kolei inny problem, w uzbrojonym po zęby postfixie (confixx 3.3.5, ruble, earl'grey, spam'esesman ;P) zaaplikowałem wpisy, które podałeś, wszystko ładnie śmiga na porcie 25 i... na 587... z jednym wyjątkiem, łącząc się z kontem przez 587 połączenie zostaje ustanowione, kiedy poczta zostaje wysłana na konto w obrębie serwera po chwili dostaję zwrotkę: : User unknown in virtual alias table... a jak wół w tej tablicy wszystko wypisane, zwrotki nie dostaję kiedy poczta wychodzi na inny serwer
i jeszcze kwestia z innej bajki, mam to życiowe szczęście mieć joomlę na serwerze i paskuda po wszystkich możliwych sztuczkach z konfigiem nie chce wysyłać maili z formularza kontaktowego (standardowy komponent), w logach postfixa nawet przy użyciu smtp cisza, inne mailery w komponentach nie robią problemów... czy postfix macza w tym palce?
Odpowiedź Lemata:
1) no_address_mappings
2) pl.comp.lang.php
2) pl.comp.lang.php
Robi
2010-01-09 20:14:56
blad przy wysylaniu do wp
Witam
wszystko zrobione wg opisu poczte odbiera i wysyla wewnatrz sieci
a u mnie pojawil sie od jakiegos czasu taki problem
w logach postfixaq mam wpis ze probuje on wyslac poczte do mx5.wp.pl na port 25 i dostaje connecion time out
opcje wysylania jakos tez trzeba przestawic czy jak ??
wszystko zrobione wg opisu poczte odbiera i wysyla wewnatrz sieci
a u mnie pojawil sie od jakiegos czasu taki problem
w logach postfixaq mam wpis ze probuje on wyslac poczte do mx5.wp.pl na port 25 i dostaje connecion time out
opcje wysylania jakos tez trzeba przestawic czy jak ??
Odpowiedź Lemata:
nie, albo padł im serwer, albo admini wp cię nie lubią, albo masz jakieś urządzenie po drodze blokujące połączenia.
x51
2010-01-15 08:52:29
Witam,
Próbuje dodac obsługe tego portu dla usługoi smtp niestety po przekopiowaniu reguł, postfix nie startuje.
SASL jest uruchomiony i nie ma problemów z wysyłką,z poza neo.
Co może byc powodem ?
SASL jest uruchomiony i nie ma problemów z wysyłką,z poza neo.
Co może byc powodem ?
Odpowiedź Lemata:
potrzebna ci wróżka. Wróżki rezydują na pl.comp.mail.mta.
tit0
2010-01-19 18:56:17
problem z wysylaniem
nie widac portu 587 ... tzn. poczta na 25 wysyla sie ... po konfiguracji w/g wyzej wymienionego opisu ... w sieci lokalenj dziala, natomiast gdy proboje wyslac wiadomosc z lacza innego niz tego gdzie jest serwer ... zwraca komuniakt ze serwer nie nasluchuje na tym porcie ... a tam nie ma zadnych regul nic na firewallu
jakis pomysl ?
jakis pomysl ?
Odpowiedź Lemata:
firewall - gdziekolwiek po drodze
Dushek
2010-01-29 15:02:54
Dzieki
Cześć,
Zadziałało od pierwszego kopa. Muszę przyznać, że masz absolutną rację, niektórzy zupełnie nie nadają się na admina. Dawny klient/admin dopiero teraz zwrócił się o pomoc w sprawie "problemów" z pocztą.
Pozdrowienia!
Zadziałało od pierwszego kopa. Muszę przyznać, że masz absolutną rację, niektórzy zupełnie nie nadają się na admina. Dawny klient/admin dopiero teraz zwrócił się o pomoc w sprawie "problemów" z pocztą.
Pozdrowienia!
Gregor
2010-03-19 10:09:26
Redirect
A co jest złego w przekierowaniu, które dziala w 100%???
Sprawe rozwiązuje jedna regułka
iptables -t nat -I PREREOUTING -p tcp --dport 587 -j DNAT adres_serwera:25
Albo z opcja REDIRECT jak kto woli.
Unika się wtedy ustawiania kolejnych restrykcji dla wysyłających odbierających itp. Nic wiecej sie nie zmienia.
Sprawe rozwiązuje jedna regułka
iptables -t nat -I PREREOUTING -p tcp --dport 587 -j DNAT adres_serwera:25
Albo z opcja REDIRECT jak kto woli.
Unika się wtedy ustawiania kolejnych restrykcji dla wysyłających odbierających itp. Nic wiecej sie nie zmienia.
Odpowiedź Lemata:
regułki na porcie 587 mają być inne niż te na porcie 25
witek
2010-03-26 12:10:44
zminana na port 587 i Connection refused
dadałem do master.cf i i przy wysyłaniu mam blad
Connection refused
111 Can't open SMTP stream
a telnet pokazuje mi cos takiego
telnet localhost 587
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Connection closed by foreign host.
Connection refused
111 Can't open SMTP stream
a telnet pokazuje mi cos takiego
telnet localhost 587
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Connection closed by foreign host.
Odpowiedź Lemata:
właściwe zadawania takich pytań miejsce to pl.comp.mail.mta
być może masz firewalla, być może zrobiłeś literówkę w master.cf
być może nie zrestartowałeś postfixa
być może masz firewalla, być może zrobiłeś literówkę w master.cf
być może nie zrestartowałeś postfixa
thomsonik
2010-05-25 15:03:56
dialog -blokada portu 25, a wysyłanie maili
witam,
mam pytanie czy jeżeli mam serwer postfix na łączu dialogu, gdzie zablokowali port 25 to wystarczy zastosować powyższą procedurę i serwer będzie w stanie wysyłać maile ? czy jest to tylko umożliwienie klientom którzy mają zablokowany port 25 połączenia do serwera ? skonfigurowałem postfixa jak powyżej, ale dalej ani przez klienta, ani przez www nie mam możliwości wysyłania poczty w świat(lokalnie działa), z tego co widzę postfix próbuje wysyłać dalej po porcie 25, który jest zablokowany, mogę prosić o jakiś komentarz w czym się mylę ? lub jak można to rozwiązać ?
wiem że to nie forum, ale będę wdzięczny za odpowiedź.
mam pytanie czy jeżeli mam serwer postfix na łączu dialogu, gdzie zablokowali port 25 to wystarczy zastosować powyższą procedurę i serwer będzie w stanie wysyłać maile ? czy jest to tylko umożliwienie klientom którzy mają zablokowany port 25 połączenia do serwera ? skonfigurowałem postfixa jak powyżej, ale dalej ani przez klienta, ani przez www nie mam możliwości wysyłania poczty w świat(lokalnie działa), z tego co widzę postfix próbuje wysyłać dalej po porcie 25, który jest zablokowany, mogę prosić o jakiś komentarz w czym się mylę ? lub jak można to rozwiązać ?
wiem że to nie forum, ale będę wdzięczny za odpowiedź.
Odpowiedź Lemata:
potrzebny ci smarthost czyli serwer na statycznym IP na którym będziesz miał konto (login i hasło lub inną metodę uwierzytelnienia), który będzie pośredniczył dla ciebie w wysyłaniu poczty. Stosunkowo mało serwerów SMTP ma w ogóle otwarty port 587 a z tych naprawdę niewiele przyjmie pocztę na porcie 587 bez loginu i hasła.
thomsonik
2010-05-27 11:04:02
odbieranie maili
witam, udało się z dialogiem załatwić, że odblokowali mi port 25, maile wychodzą już w świat mam jednak problem, gdyż nie mogę odbierać maili, na moim routerze za którym stoi maszyna z postfixem widać logi, że coś z serwera czy to wp czy onetu łączy się i dobija na ip postfixa na port 25, ale w mail.log na postfixie nie ma nic o tym zdarzeniu, ale raz na kilka godzin maile nagle wydaje się, że wszystkie nagle dochodzą na serwer do tego w kolejności innej niż zostały wysłane i nie mam pojęcia jak zdiagnozować problem, jeżeli widać na routerze że coś dobija się na serwer pocztowy eliminuje to dialog i blokadę portu 25, router też przekazuje, serwer jednak jak nie ma nic w mail.log to nic nie dochodzi, czyli jakby blokowane było przez np. firewall na linuxie(ale wyłączyłem) i raz na jakis czas dochodzą maile, mam zainstalowanego postfixa, docvecota, spamassasina+razor i clamav + amavis'ta na debianie stable, czy mogę prosić o jakieś sugestie jak taki problem zdiagnozować ?
Odpowiedź Lemata:
sugestia: przetłumacz na polski od piątego do ósmego przecinka.
jbw
2010-06-10 13:11:19
z mojej praktyki
Wykorzystałem "szum medialny" wokół blokady portu 25 aby przepędzić wszystkich swoich userów na port 587, z obowiązkowym SASL+TLS, bez względu na to, za pośrednictwem czego się łączą.
Pragnę podkreślić, co nie było tu wystarczająco mocno zaakcentowane, że wprowadzenie tylko uwierzytelnienia bez ochrony szyfrowaniem oddaje hasło na pastwę snifferów. A ponieważ powszechną praktyką jest używanie jednego hasła do wysyłania i odbierania poczty, skutki tego mogą być opłakane.
Napisałem skrypt analizujący logi pocztowe w połączeniu z prostym interfejsem www, gdzie widzę jaką metodą userzy się ostatnio łączyli. Dzięki temu mogłem pogonić pojedynczych maruderów do zmiany - i przed "godziną zero" wszyscy byli gotowi.
Wysyp pytań w komentarzach, czemu przekierowanie portu jest niedobre, potwierdza złą opinię o poziomie wiedzy adminów. Dla mnie rozdzielenie poczty od użytkowników i od serwerów stało się okazją do drastycznej radykalizacji reguł filtrowania na porcie 25, np. całkowicie odrzucam teraz non-fqdn HELO.
Skutek jest taki, że praktycznie zapomniałem co to jest spam. W ciągu minionego kwartału dostałem 2 lub 3 takie listy. Inni użytkownicy (jest ich około setki) też nie narzekają. Tymczasem zatrzymanych zostało, chwileczkę, zerknę... 17244 prób dostarczenia poczty, z samych tylko względów formalnych. Do tego trzeba doliczyć 876 odrzuconych nadawców z czarnych list oraz nieokreśloną ich liczbę, którzy nie przeszli szarolistnej procedury.
Z drugiej strony, zwiększył się komfort użytkowników, którzy teraz ślą pocztę skąd chcą, bez żadnych obstrukcji.
Warto też zauważyć dodatkową, uboczną korzyść z uwierzytelnienia, jaką jest pewność autorstwa. Opcja postfix-a
smtpd_sasl_authenticated_header = yes
umieszcza w liście wzmiankę, kto odpowiada za nadanie go.
Jedyny problem jaki pojawił się w całym tym przedsięwzięciu, to certyfikat serwera. Do tej pory używałem, jak większość linuksowców-amatorów, "samopodpisanego" certyfikatu i wymuszałem na użytkownikach zaakceptowanie go u siebie. Choć jest to nieprofesjonalna praktyka, trudno ode mnie wymagać zakupu "prawdziwego" certyfikatu na potrzeby usługi świadczonej nieodpłatnie. Nieoczekiwanie i ku wielkiej mej radości, odkryłem firmę StartCOM, która wydaje nieodpłatnie proste certyfikaty, w zupełności wystarczające dla amatorskiego serwera. Od niedawna aktualizacje certyfikatów głównych dla Windows zawierają ten urząd na liście zaufanych wystawców. Nie podaję adresu, szukajcie a znajdziecie.
I jeszcze drobne wyjaśnienie: mówiąc "amatorski" mam na myśli sposób finansowania, a nie poziom świadczonych usług ;-)
Pragnę podkreślić, co nie było tu wystarczająco mocno zaakcentowane, że wprowadzenie tylko uwierzytelnienia bez ochrony szyfrowaniem oddaje hasło na pastwę snifferów. A ponieważ powszechną praktyką jest używanie jednego hasła do wysyłania i odbierania poczty, skutki tego mogą być opłakane.
Napisałem skrypt analizujący logi pocztowe w połączeniu z prostym interfejsem www, gdzie widzę jaką metodą userzy się ostatnio łączyli. Dzięki temu mogłem pogonić pojedynczych maruderów do zmiany - i przed "godziną zero" wszyscy byli gotowi.
Wysyp pytań w komentarzach, czemu przekierowanie portu jest niedobre, potwierdza złą opinię o poziomie wiedzy adminów. Dla mnie rozdzielenie poczty od użytkowników i od serwerów stało się okazją do drastycznej radykalizacji reguł filtrowania na porcie 25, np. całkowicie odrzucam teraz non-fqdn HELO.
Skutek jest taki, że praktycznie zapomniałem co to jest spam. W ciągu minionego kwartału dostałem 2 lub 3 takie listy. Inni użytkownicy (jest ich około setki) też nie narzekają. Tymczasem zatrzymanych zostało, chwileczkę, zerknę... 17244 prób dostarczenia poczty, z samych tylko względów formalnych. Do tego trzeba doliczyć 876 odrzuconych nadawców z czarnych list oraz nieokreśloną ich liczbę, którzy nie przeszli szarolistnej procedury.
Z drugiej strony, zwiększył się komfort użytkowników, którzy teraz ślą pocztę skąd chcą, bez żadnych obstrukcji.
Warto też zauważyć dodatkową, uboczną korzyść z uwierzytelnienia, jaką jest pewność autorstwa. Opcja postfix-a
smtpd_sasl_authenticated_header = yes
umieszcza w liście wzmiankę, kto odpowiada za nadanie go.
Jedyny problem jaki pojawił się w całym tym przedsięwzięciu, to certyfikat serwera. Do tej pory używałem, jak większość linuksowców-amatorów, "samopodpisanego" certyfikatu i wymuszałem na użytkownikach zaakceptowanie go u siebie. Choć jest to nieprofesjonalna praktyka, trudno ode mnie wymagać zakupu "prawdziwego" certyfikatu na potrzeby usługi świadczonej nieodpłatnie. Nieoczekiwanie i ku wielkiej mej radości, odkryłem firmę StartCOM, która wydaje nieodpłatnie proste certyfikaty, w zupełności wystarczające dla amatorskiego serwera. Od niedawna aktualizacje certyfikatów głównych dla Windows zawierają ten urząd na liście zaufanych wystawców. Nie podaję adresu, szukajcie a znajdziecie.
I jeszcze drobne wyjaśnienie: mówiąc "amatorski" mam na myśli sposób finansowania, a nie poziom świadczonych usług ;-)
Ładowny
2011-04-08 03:33:20
firma StartCOM
Dzięki Lemat, w parę minut dodałem w swoim postfixie obsługę portu 587. Do tej pory nie potrzebowałem, ale mój nowy internet przez komórkę ma zablokowany port 25. Natomiast w komentarzach wyczytałem o darmowych certyfikatach i się tym zainteresowałem. Poniżej moje spostrzeżenia. Może warto podpiąć pod posta zachęcającego do skorzystania z usług.
Do jbw - piszesz "odkryłem firmę StartCOM, która wydaje nieodpłatnie proste certyfikaty, w zupełności wystarczające dla amatorskiego serwera. Od niedawna aktualizacje certyfikatów głównych dla Windows zawierają ten urząd na liście zaufanych wystawców."
No cóż, sprawdziłem. I tak.
Do Windows (IE) tak, ale np. windows mail już tych certyfikatów nie akceptuje i się pluje ( z certyfikatami z np. Digicert czy Equifax nie ma problemu - mam ich ze 20 dla róznych klientów ). Tak samo Firefox. Google Chrome akceptuje, ale mam to na tej samej wirtualce z której się rejestrowałem, więc nie jestem pewien.
Oni robią prosty trick - rejestrują swój certyfikat w komputerze jako zaufany podczas procesu rejestracji u nich, więc na tym komputerze wszystkie odwołania będą ok. Gorzej z komputerami innych użytkowników. Zainstalowałem ich certyfikat i wszedłem na stronę Firefoxem z innego komputera ( wirtualki ). I dostałem standardowe ostrzeżenie o niezaufanym certyfikacie. IE faktycznie ten certyfikat łyka. Ale co z użytkownikami MAC'ów, Linux'a i przeglądarek innych niż IE ?
Natmiast samo "za darmo" wygląda lekko podejrzanie, niby za darmo ale "Even though StartSSL™ provides certificates generally free of charge, revocations thereof may carry a handling fee." Czyli jak zgubimy klucz prywatny lub co gorzej dostanie się w niepowołane ręce, to trzeba bulić. Nie doszukałem się ile.
Na ich plus zaliczam to, że pozwalają wrzucić samodzielnie wygenerowany CSR, na minus to, że domyślnie próbują wygenerować wszystko za nas, w tym klucz prywatny. Czyli jak ktoś skorzysta z tej opcji ( ja nie skorzystałem, klucze prywatne wolę generować sam ) i klucz zgubi albo co gorsza ktoś go przejmie, to problem gotowy.
Generalnie, rozwiązanie do domowych serwerków. Nie polecałbym stosować w firmowych zastosowaniach, bo można się nieźle przejechać. Tylko do domowych serwerków wystarczy samodzielnie wygenerowany certyfikat. Nie trzeba się nigdzie rejestrować, podawać danych itp. Wystarczy poprosić użytkowników serwerka o dodanie klucza do zaufanych urzędów certyfikacji.
Do jbw - piszesz "odkryłem firmę StartCOM, która wydaje nieodpłatnie proste certyfikaty, w zupełności wystarczające dla amatorskiego serwera. Od niedawna aktualizacje certyfikatów głównych dla Windows zawierają ten urząd na liście zaufanych wystawców."
No cóż, sprawdziłem. I tak.
Do Windows (IE) tak, ale np. windows mail już tych certyfikatów nie akceptuje i się pluje ( z certyfikatami z np. Digicert czy Equifax nie ma problemu - mam ich ze 20 dla róznych klientów ). Tak samo Firefox. Google Chrome akceptuje, ale mam to na tej samej wirtualce z której się rejestrowałem, więc nie jestem pewien.
Oni robią prosty trick - rejestrują swój certyfikat w komputerze jako zaufany podczas procesu rejestracji u nich, więc na tym komputerze wszystkie odwołania będą ok. Gorzej z komputerami innych użytkowników. Zainstalowałem ich certyfikat i wszedłem na stronę Firefoxem z innego komputera ( wirtualki ). I dostałem standardowe ostrzeżenie o niezaufanym certyfikacie. IE faktycznie ten certyfikat łyka. Ale co z użytkownikami MAC'ów, Linux'a i przeglądarek innych niż IE ?
Natmiast samo "za darmo" wygląda lekko podejrzanie, niby za darmo ale "Even though StartSSL™ provides certificates generally free of charge, revocations thereof may carry a handling fee." Czyli jak zgubimy klucz prywatny lub co gorzej dostanie się w niepowołane ręce, to trzeba bulić. Nie doszukałem się ile.
Na ich plus zaliczam to, że pozwalają wrzucić samodzielnie wygenerowany CSR, na minus to, że domyślnie próbują wygenerować wszystko za nas, w tym klucz prywatny. Czyli jak ktoś skorzysta z tej opcji ( ja nie skorzystałem, klucze prywatne wolę generować sam ) i klucz zgubi albo co gorsza ktoś go przejmie, to problem gotowy.
Generalnie, rozwiązanie do domowych serwerków. Nie polecałbym stosować w firmowych zastosowaniach, bo można się nieźle przejechać. Tylko do domowych serwerków wystarczy samodzielnie wygenerowany certyfikat. Nie trzeba się nigdzie rejestrować, podawać danych itp. Wystarczy poprosić użytkowników serwerka o dodanie klucza do zaufanych urzędów certyfikacji.
Sethiel
2012-11-12 15:12:47
podwójny smtpd_sender_restrictions
Nie lepiej dać to w jednej linii?
-o smtpd_sender_restrictions=reject_sender_login_mismatch,permit_sasl_authenticated,reject
-o smtpd_sender_restrictions=reject_sender_login_mismatch,permit_sasl_authenticated,reject
Odpowiedź Lemata:
jak zawsze trąbię: wszystko co się dotyczy recipienta powinno być skonfigurowane dopiero w smtpd_recipient_restrictions
chrees
2014-01-20 07:45:33
przetwarzanie konfiguracji w main.cf
Przy tej konfiguracji niemal w 100% jest pomijana konfiguracja main.cf. Przykładowo u mnie pomijany był łańcuch smtpd_recipient_restrictions, w którym zawarłem dość specyficzne ustawienia serwera. Wobec tego client, który łączył się za pomocą portu 587, mógł zdziałać dużo więcej, niż ten z 25.
Z tym sobie poradziłem komentując -o z tym łańcuchem. Natomiast pozostał jeszcze jeden problem. Jeśli z serwerem łączy się client po tym porcie i wysyła maila na adres, który u mnie jest aliasem zdefiniowanym w bazie danych, to serwer uparcie dostarcza go na konto o takim samym adresie, a nie na alias. Jeśli komunikacja odbywa się po porcie 25, to jest wszystko ok.
Jak zrobić, by tak samo było dla portu 587?
Z tym sobie poradziłem komentując -o z tym łańcuchem. Natomiast pozostał jeszcze jeden problem. Jeśli z serwerem łączy się client po tym porcie i wysyła maila na adres, który u mnie jest aliasem zdefiniowanym w bazie danych, to serwer uparcie dostarcza go na konto o takim samym adresie, a nie na alias. Jeśli komunikacja odbywa się po porcie 25, to jest wszystko ok.
Jak zrobić, by tak samo było dla portu 587?
Odpowiedź Lemata:
1) i dokładnie tak ma być, że klient na porcie 587 ma mieć inne restrykcje niż klient na porcie 25
2) no address mappings
2) no address mappings