🚀 go-pugleaf

Dnia Mon, 12 Jun 2017 14:57:47 +0200, LFC napisał(a):

> Jest sieć niepubliczna 192.168.0.0, która stoi za NAT. Hosty w sieci z 
> adresami niepublicznymi łączą się z Serwerem smtp sendmail i pop3 
> dovecot. Układ funkcjonuje dobrze od dawna, ale do jednego z odbiorców 
> poczta nie dochodzi i dostajemy komunikar o błędzie:
> 
> The original message was received at Mon, 12 Jun 2017 13:22:27 +0200
> from [192.168.0.172]
> 
>     ----- The following addresses had permanent fatal errors -----
> <user.nazwisko@nik.gov.pl>
>      (reason: 554 5.7.1 <host.domena.com.pl>: Helo command rejected: 
> mail server in RFC 1918 private network)
> 
>     ----- Transcript of session follows -----
> ... while talking to mx.nik.gov.pl.:
>  >>> DATA
> <<< 554 5.7.1 <mpwik.mpwikzdw.com.pl>: Helo command rejected: mail 
> server in RFC 1918 private network
> 554 5.0.0 Service unavailable
> <<< 554 5.5.1 Error: no valid recipients
> 
> Server stoi na tym samym hoście, który robi NAT i dla świata widoczny 
> jest z publicznym IP.
> Czyzby serwer NIK czepiał się adresu hosta wysyłającego pocztę
> 
> LFC

Sprawdź z jakim adresem wychodzi komunikacja z twojej sieci do
mx.nik.gov.pl na port 25.
Być może jednak NAT w tym konkretnym przypadku jest pominięty (może
przez jakiś tunel)?

-- 
pozdrawiam
Sylwester Zarębski

Aby wysłać email zmień zbieracz w adresie na sylwek

On 2017-06-12, LFC <longinf@mpwikzdw.com.pl> wrote:
> Jest sieć niepubliczna 192.168.0.0, która stoi za NAT. Hosty w sieci z 
> adresami niepublicznymi łączą się z Serwerem smtp sendmail i pop3 
> dovecot. Układ funkcjonuje dobrze od dawna, ale do jednego z odbiorców 
> poczta nie dochodzi i dostajemy komunikar o błędzie:
>
> The original message was received at Mon, 12 Jun 2017 13:22:27 +0200
> from [192.168.0.172]
>
>     ----- The following addresses had permanent fatal errors -----
><user.nazwisko@nik.gov.pl>
>      (reason: 554 5.7.1 <host.domena.com.pl>: Helo command rejected: 
> mail server in RFC 1918 private network)

Tu masz przyczynę - w HELO/EHLO Twój serwer przedstawia się
"[192.168.0.172]". Nie wiem jak się to ustawia w sendmail, ale
powinieneś tam wpisać nazwę serwera pod jaką jest widoczny ze świata.

-- 
Pozdrawiam,
Marek Marczykowski          | RLU #390519
marmarek at staszic waw pl  | xmpp:marmarek at staszic waw pl

W dniu 12.06.2017 o 14:57, LFC pisze:
> Jest sieć niepubliczna 192.168.0.0, która stoi za NAT. Hosty w sieci z 
> adresami niepublicznymi łączą się z Serwerem smtp sendmail i pop3 
> dovecot. Układ funkcjonuje dobrze od dawna, ale do jednego z odbiorców 
> poczta nie dochodzi i dostajemy komunikar o błędzie:

>      (reason: 554 5.7.1 <host.domena.com.pl>: Helo command rejected: 
> mail server in RFC 1918 private network)



host.domena.com.pl IN A 192.168.0.cośtam
zmień na
host.domena.com.pl IN A zewn.add.ress.IP

-- 
Pozdrawiam
Lemat

W dniu 12.06.2017 o 16:54, Lemat pisze:

>
>
> host.domena.com.pl IN A 192.168.0.cośtam
> zmień na
> host.domena.com.pl IN A zewn.add.ress.IP
>
Jest tak. W dns są 2 widoki. W externalu jest tylko adres publiczny.
Fakt, że był również niepubliczny, ale do tej pory nie było z tym 
problemu. Tylko serwer NIK protestuje. Usunąłem z widoku zewnętrznego 
adresy niepubliczne, ale na ta chwilę nic się nie zmieniło.
Zastanawiam się, czy nie boli go to, że w każej wysłanej poczcie jest 
received from: adres niepubliczny hosta z sieci niepublicznej.
Chyba, że propagacja DNS zabiera więcej czasu.
Zastanawiam się, czy opcja z konfigu: MASQUERADE_AS(host.domain), to nie 
jest właśnie to, czego trzeba, bo o ile dobrze zrozumiałem maskuje ona 
właśnie hosty, które które wysyłaja pocztę.

LFC

W dniu 12.06.2017 o 20:01, LFC pisze:
> W dniu 12.06.2017 o 16:54, Lemat pisze:
> 
>>
>>
>> host.domena.com.pl IN A 192.168.0.cośtam
>> zmień na
>> host.domena.com.pl IN A zewn.add.ress.IP
>>
> Jest tak. W dns są 2 widoki. W externalu jest tylko adres publiczny.
> Fakt, że był również niepubliczny, ale do tej pory nie było z tym 
> problemu. Tylko serwer NIK protestuje. 

Mój też by protestował a komunikat wygląda jak wyjęty żywcem z mojej, 
publicznie dostępnej konfiguracji.

> Usunąłem z widoku zewnętrznego 
> adresy niepubliczne, ale na ta chwilę nic się nie zmieniło.

są serwery keszujące rekordy DNS na TTL czasu - po każdej zmianie musisz 
odczekać TTL sekund aby serwery keszujące zgubiły twoje rekordy i 
pobrały nowe z twoich serwerów DNS.

> Zastanawiam się, czy nie boli go to, że w każej wysłanej poczcie jest 
> received from: adres niepubliczny hosta z sieci niepublicznej.

nie dochodzi do przesłania nagłówków i treści emaila. Jest on odrzucany 
w sesji przed DATA.

> Chyba, że propagacja DNS zabiera więcej czasu.

O właśnie. Brakowało mi tego słowa.

> Zastanawiam się, czy opcja z konfigu: MASQUERADE_AS(host.domain), to nie 
> jest właśnie to, czego trzeba, bo o ile dobrze zrozumiałem maskuje ona 
> właśnie hosty, które które wysyłaja pocztę.

nie panikuj, poczekaj TTL czasu.

-- 
Pozdrawiam
Lemat

W dniu 12.06.2017 o 22:14, Lemat pisze:

>
>> Chyba, że propagacja DNS zabiera więcej czasu.
>
> O właśnie. Brakowało mi tego słowa.
>
>> Zastanawiam się, czy opcja z konfigu: MASQUERADE_AS(host.domain), to
>> nie jest właśnie to, czego trzeba, bo o ile dobrze zrozumiałem maskuje
>> ona właśnie hosty, które które wysyłaja pocztę.
>
> nie panikuj, poczekaj TTL czasu.
>

Niestety dzisiaj jest to samo. Nie da sie chyba zwalić tego na DNS.
Spróbuję opcji maskującej.

W dniu 13.06.2017 o 07:12, LFC pisze:
> W dniu 12.06.2017 o 22:14, Lemat pisze:
> 
>>
>>> Chyba, że propagacja DNS zabiera więcej czasu.
>>
>> O właśnie. Brakowało mi tego słowa.
>>
>>> Zastanawiam się, czy opcja z konfigu: MASQUERADE_AS(host.domain), to
>>> nie jest właśnie to, czego trzeba, bo o ile dobrze zrozumiałem maskuje
>>> ona właśnie hosty, które które wysyłaja pocztę.
>>
>> nie panikuj, poczekaj TTL czasu.
>>
> 
> Niestety dzisiaj jest to samo. Nie da sie chyba zwalić tego na DNS.
> Spróbuję opcji maskującej.
> 
> 

ustaw aby serwer przedstawiał się innym EHLO - cośtam.twoja.domena
ustaw wcześniej taki wpis w DNS

-- 
Pozdrawiam
Lemat

W dniu 13.06.2017 o 07:12, LFC pisze:
> 
> Niestety dzisiaj jest to samo. Nie da sie chyba zwalić tego na DNS.
> Spróbuję opcji maskującej.

To może trwać nawet tydzień.
-- 
Olek

W dniu 13.06.2017 o 16:18, Lemat pisze:

>>
>
> ustaw aby serwer przedstawiał się innym EHLO - cośtam.twoja.domena
> ustaw wcześniej taki wpis w DNS
>

Przedstawia się HELO mpwik.mpwikzdw.com.pl.....

Tu wszystko jest w klasie host ma adres publiczny, taki sam, jak domena

To działa bardzo dobrze. W zasadzie nie ma żadnych problemów - gada ze 
wszystkimi serwerami. Dorzuciłem mu nawet dodatkowo certyfikat 
Diffie-Hellmana, zeby gadał bezproblemowo z niektórymi serwerami banków.
Tylko ten z NIK marudzi.

Wydaje mi się, że chodzi o to:

Received: from mx.poczta.onet.pl (unresolved [10.174.34.83]:38686)
	by ps17.m5r2.onet (Ota) with LMTP id 457EC3029B72D
	for <longinf@poczta.onet.pl>; Tue, 13 Jun 2017 12:50:01 +0200 (CEST)
Received: from mpwik.mpwikzdw.com.pl (dns.mpwikzdw.com.pl [194.150.251.249])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mx.poczta.onet.pl (Onet) with ESMTPS id 3wn63Y1HMTzBC
	for <longinf@poczta.onet.pl>; Tue, 13 Jun 2017 12:50:01 +0200 (CEST)
Received: from longinf.mpwikzdw.com.pl ([192.168.0.172])
	(authenticated bits=0)
	by mpwik.mpwikzdw.com.pl (8.14.4/8.13.8) with ESMTP id v5DAnxsh032131
	for <longinf@poczta.onet.pl>; Tue, 13 Jun 2017 12:49:59 +0200

Tak wygląda fragment widoku źródłowego poczty wysłanej z naszej sieci na 
zewnątrz.
To ostatnie, a właściwie pierwsze Received:, czyli z hosta w sieci 
lokalnej do serwera.
Innego powodu nie widzę i nie bardzo rozumiem, dlaczego miałoby mu to 
przeszkadzać.
Opcja MASQUERADE_AS niestety nic nie zmieniła

LFC

Dnia Wed, 14 Jun 2017 07:29:29 +0200, LFC napisał(a):

> W dniu 13.06.2017 o 16:18, Lemat pisze:
> 
>> ustaw aby serwer przedstawiał się innym EHLO - cośtam.twoja.domena
>> ustaw wcześniej taki wpis w DNS
> 
> Przedstawia się HELO mpwik.mpwikzdw.com.pl.....
> 
> Tu wszystko jest w klasie host ma adres publiczny, taki sam, jak domena
> 
> To działa bardzo dobrze. W zasadzie nie ma żadnych problemów - gada ze 
> wszystkimi serwerami. Dorzuciłem mu nawet dodatkowo certyfikat 
> Diffie-Hellmana, zeby gadał bezproblemowo z niektórymi serwerami banków.
> Tylko ten z NIK marudzi.
> 
> Wydaje mi się, że chodzi o to:
> 
> Received: from mx.poczta.onet.pl (unresolved [10.174.34.83]:38686)
> 	by ps17.m5r2.onet (Ota) with LMTP id 457EC3029B72D
> 	for <longinf@poczta.onet.pl>; Tue, 13 Jun 2017 12:50:01 +0200 (CEST)
> Received: from mpwik.mpwikzdw.com.pl (dns.mpwikzdw.com.pl [194.150.251.249])
> 	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
> 	(No client certificate requested)
> 	by mx.poczta.onet.pl (Onet) with ESMTPS id 3wn63Y1HMTzBC
> 	for <longinf@poczta.onet.pl>; Tue, 13 Jun 2017 12:50:01 +0200 (CEST)
> Received: from longinf.mpwikzdw.com.pl ([192.168.0.172])
> 	(authenticated bits=0)
> 	by mpwik.mpwikzdw.com.pl (8.14.4/8.13.8) with ESMTP id v5DAnxsh032131
> 	for <longinf@poczta.onet.pl>; Tue, 13 Jun 2017 12:49:59 +0200
> 
> Tak wygląda fragment widoku źródłowego poczty wysłanej z naszej sieci na 
> zewnątrz.
> To ostatnie, a właściwie pierwsze Received:, czyli z hosta w sieci 
> lokalnej do serwera.
> Innego powodu nie widzę i nie bardzo rozumiem, dlaczego miałoby mu to 
> przeszkadzać.
> Opcja MASQUERADE_AS niestety nic nie zmieniła
> 
> LFC

Jeśli miałeś gdzieś w publicznym DNS adres prywatny, poczekaj aż się
rozpropaguje. Może to być nawet tydzień (jak już pisano).

Nie sądzę, aby chodziło o Received, gdyż komunikat błędu dotyczy
HELO/EHLO, a przynajmniej tak jest opisany. Zresztą, nie są mi znane
żadne RFC, które by zastrzegały użycie adresacji prywatnej w nagłówkach
Received.

-- 
pozdrawiam
Sylwester Zarębski

Aby wysłać email zmień zbieracz w adresie na sylwek

W dniu 14.06.2017 o 09:00, Sylwester Zarębski pisze:

>> LFC
>
> Jeśli miałeś gdzieś w publicznym DNS adres prywatny, poczekaj aż się
> rozpropaguje. Może to być nawet tydzień (jak już pisano).
>
Tzn. Zmiany  w strefie, przynajmniej do secondary u providera dość 
szybko się dokonują, tak z obserwacji, są właściwie natychmiastowe.
Nie wiem jak dalej.

> Nie sądzę, aby chodziło o Received, gdyż komunikat błędu dotyczy
> HELO/EHLO, a przynajmniej tak jest opisany. Zresztą, nie są mi znane
> żadne RFC, które by zastrzegały użycie adresacji prywatnej w nagłówkach
> Received.
>
Też mi się wydaje to dziwne, chyba, że chodzi im o wychwytywanie spamu 
-sporo ze spamu ma tak w żródle z prywatnego adresu na relaya i dalej.
Wtedy jakiś milter, np w sendmailu moze to być regex-milter moze ciąć po 
wybranej zawartości w nagłówku, a serwer nie wali jej w spam tylko 
odrzuca pocztę z odpowiednim komunikatem.

LFC

Dnia Wed, 14 Jun 2017 14:15:07 +0200, LFC napisał(a):

> W dniu 14.06.2017 o 09:00, Sylwester Zarębski pisze:
> 
>> Jeśli miałeś gdzieś w publicznym DNS adres prywatny, poczekaj aż się
>> rozpropaguje. Może to być nawet tydzień (jak już pisano).
>>
> Tzn. Zmiany  w strefie, przynajmniej do secondary u providera dość 
> szybko się dokonują, tak z obserwacji, są właściwie natychmiastowe.
> Nie wiem jak dalej.

DNSy po stronie odbiorcy mogą przechowywać informację w cache wg
własnego uznania.

>> Nie sądzę, aby chodziło o Received, gdyż komunikat błędu dotyczy
>> HELO/EHLO, a przynajmniej tak jest opisany. Zresztą, nie są mi znane
>> żadne RFC, które by zastrzegały użycie adresacji prywatnej w nagłówkach
>> Received.
>>
> Też mi się wydaje to dziwne, chyba, że chodzi im o wychwytywanie spamu 
> -sporo ze spamu ma tak w żródle z prywatnego adresu na relaya i dalej.
> Wtedy jakiś milter, np w sendmailu moze to być regex-milter moze ciąć po 
> wybranej zawartości w nagłówku, a serwer nie wali jej w spam tylko 
> odrzuca pocztę z odpowiednim komunikatem.

A czy próbowałeś skontaktować się z administratorem serwera odbiorcy?

-- 
pozdrawiam
Sylwester Zarębski

Aby wysłać email zmień zbieracz w adresie na sylwek

W dniu 14.06.2017 o 16:43, Sylwester Zarębski pisze:
> Dnia Wed, 14 Jun 2017 14:15:07 +0200, LFC napisał(a):
> .
>
> DNSy po stronie odbiorcy mogą przechowywać informację w cache wg
> własnego uznania.

Byłoby dziwne, gdyby miały jakies super długie czasy.


> A czy próbowałeś skontaktować się z administratorem serwera odbiorcy?
>

Nie próbowałem. Do tej pory próbowałem rozwiązać problem od swojej 
strony - bezskutecznie.
Jeżeli będzie jeszcze potrzebna komunikacja mailowa w ich stronę, to 
trzeba będzie.

LFC

Dnia Fri, 16 Jun 2017 11:53:19 +0200, LFC napisał(a):

> W dniu 14.06.2017 o 16:43, Sylwester Zarębski pisze:
[...]
>> DNSy po stronie odbiorcy mogą przechowywać informację w cache wg
>> własnego uznania.
> 
> Byłoby dziwne, gdyby miały jakies super długie czasy.

Tydzień w cache nie jest wcale dziwne.

>> A czy próbowałeś skontaktować się z administratorem serwera odbiorcy?
> Nie próbowałem. Do tej pory próbowałem rozwiązać problem od swojej 
> strony - bezskutecznie.
> Jeżeli będzie jeszcze potrzebna komunikacja mailowa w ich stronę, to 
> trzeba będzie.

Spróbuj, najszybciej uzyskasz informację zwrotną, bo do tej pory
opieramy się na poszlakach (co prawda mocnych, ale jednak). Serwer
mx.nik.gov.pl jest administracji publicznej, kto wie, co tam zostało
ustawione ;).

-- 
pozdrawiam
Sylwester Zarębski

Aby wysłać email zmień zbieracz w adresie na sylwek

W dniu 16.06.2017 o 12:45, Sylwester Zarębski pisze:
> Dnia Fri, 16 Jun 2017 11:53:19 +0200, LFC napisał(a):
>
>> W dniu 14.06.2017 o 16:43, Sylwester Zarębski pisze:
> [...]
>>> DNSy po stronie odbiorcy mogą przechowywać informację w cache wg
>>> własnego uznania.
>>
>> Byłoby dziwne, gdyby miały jakies super długie czasy.
>
> Tydzień w cache nie jest wcale dziwne.
>

Prawda. Długo im zajęło odswieżenie DNS, ale jest już OK.

Nawet nie mógłbym wysłać do admina poczty, bo pewnie odrzuciłoby ją z 
tym samym komunikatem.

LFC