Komentarze i odpowiedzi, posortowane dla odmiany chronologicznie do strony:

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-

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.

Dlaczego "Da się, powinno nawet działać, ale pomysł jest moim zdaniem kretyński."?

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"

Wpisałem jak powyzej, ale postfix nie nasluchuje na porcie 587

587/tcp closed submission

W iptables wpuszczam wiec w czym problem?

Jest błąd: User unknown in virtual alias table
Pozdrawiam

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.

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

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?

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 ??

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 ?

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 ?

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!

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.

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.

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ź.

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ć ?

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 ;-)

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.

Nie lepiej dać to w jednej linii?
-o smtpd_sender_restrictions=reject_sender_login_mismatch,permit_sasl_authenticated,reject

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?