Sprawdzanie HELO/EHLO

[Grzegorz Janoszka]

Włączyłem sobie testowo na maszynce pocztowej sprawdzanie HELO/EHLO.
Wiem, że odrzucanie maili tylko na podstawie nieprawdziwego
przedstawienia się jest niezgodne z RFC, ale przecież nic się nie
stanie, jak przez nockę jakieś maile skolejkuje :)

Jest to świetne rozwiązanie na wirusy i spamy - 99.99% z nich źle
przedstawia się w HELO. Problem w tym, że jest trochę polskich sieci,
które wysyłają maile ze złym powitaniem, nie będę wyliczał, ale należy
do nich np. taka interia.pl (już pomijam kwestię taką, że po wysłaniu
maila na ***@interia.pl dostaje się zwrotkę z błędem).

A w ogóle osobną kategorią są serwery smtp, które łącząc się z
uczelnia.edu.pl do firma.com.pl wpisują HELO firma.com.pl - mam dość
sporo wpisów, z których wynika, że serwer smtp wysyłając do mnie maila
przedstawił się docelową domeną...

No i pytania:
Czy ktoś testował takie coś u siebie?
Czy nie wiecie, czy jakiś MTA przedstawia się docelową domeną?

[Moon]

Post by Grzegorz Janoszka
Czy ktoś testował takie coś u siebie?
Czy nie wiecie, czy jakiś MTA przedstawia się docelową domeną?

Ja odwazylem sie na filtrowanie po HELO tylko MTA przedstawiajace sie jako
ja. Nie wiem czy jakis inny sie przedstawia domena docelowa ale watpie.
Zreszta z logow widze ze nie bylo "false positives". Glownie ta metoda
odrzucam (definitywnie - 550) wirusy i czasem trafiaja sie jakies spamy.

Pozdr.
Michal

[Dominik 'Rathann' Mierzejewski]

Date: Wed, 16 Jun 2004 09:43:48 +0000 (UTC)
From: Grzegorz Janoszka
[...]

Post by Grzegorz Janoszka
Czy ktoś testował takie coś u siebie?

Tak. Ja mam w tej chwili włączone (postfix):
smtpd_recipient_restrictions =
reject_invalid_hostname,
[...]
reject_non_fqdn_hostname,
reject_unknown_hostname,
[...]
check_helo_access hash:$config_directory/access_helo,
[...]

W tym ostatnim mam odrzucanie sesji, jeśli klient przedstawia się
moją własną domeną lub adresem IP.

Post by Grzegorz Janoszka
Czy nie wiecie, czy jakiś MTA przedstawia się docelową domeną?

Podobno klient Mozilli wysyła w HELO nazwę domeny adresu, który
podajesz we From:. Ale nie pamiętam dokładnie, więc mogę się mylić.

R.

[Grzegorz Janoszka]

Post by Dominik 'Rathann' Mierzejewski

Post by Grzegorz Janoszka
Czy ktoś testował takie coś u siebie?

smtpd_recipient_restrictions =
reject_invalid_hostname,
reject_non_fqdn_hostname,
reject_unknown_hostname,

I nie masz skarg, że maile np. z bph.pl i kilku innych (wyglądających na
ważne) domen nie przychodzą?

Post by Dominik 'Rathann' Mierzejewski

Post by Grzegorz Janoszka
Czy nie wiecie, czy jakiś MTA przedstawia się docelową domeną?

Podobno klient Mozilli wysyła w HELO nazwę domeny adresu, który
podajesz we From:. Ale nie pamiętam dokładnie, więc mogę się mylić.

No rozumiem, że bill takie coś by napisał... ale mozilla? Świat się
kończy :(

[Lech Szychowski]

Post by Grzegorz Janoszka
I nie masz skarg, że maile np. z bph.pl i kilku innych
(wyglądających na ważne) domen nie przychodzą?

Akurat BPH ma to rozwiązane jeszcze nie tak całkiem tragicznie
(pod tym względem)...

===
Jun 16 13:xx:xx ns sm-mta[5375]: ixxxxxxxxxxxxx: Authentication-Warning: ns.pse.pl: Host out1.bphpbk.pl [193.108.177.77] claimed to be mail.bph.pl
Jun 16 13:xx:xx ns sm-mta[5375]: ixxxxxxxxxxxxx: from=<***@bph.pl>, size=xxxxx, class=0, nrcpts=1, msgid=<***@bph.pl>, proto=ESMTP, daemon=MTA, relay=out1.bphpbk.pl [193.108.177.77]
===

===
$ host mail.bph.pl
mail.bph.pl has address 193.108.177.75
===

...bo przynajmniej FQDN, którym się przedstawia, istnieje.

[Grzegorz Janoszka]

Post by Lech Szychowski
Akurat BPH ma to rozwiązane jeszcze nie tak całkiem tragicznie
(pod tym względem)...
...bo przynajmniej FQDN, którym się przedstawia, istnieje.

No i? Co z tego, że istnieje, skoro to nie ten? :)

Mój MTA pozwala niestety tylko na odrzucanie maili mających złe HELO
(Courier) :(

[-IT-]

[Grzegorz Janoszka]

Post by Grzegorz Janoszka

Post by Lech Szychowski
Akurat BPH ma to rozwiązane jeszcze nie tak całkiem tragicznie
(pod tym względem)...
...bo przynajmniej FQDN, którym się przedstawia, istnieje.

No i? Co z tego, że istnieje, skoro to nie ten? :)
Mój MTA pozwala niestety tylko na odrzucanie maili mających złe HELO
(Courier) :(

Chyba Cię źle zrozumiałem. Czy złe to takie, które udają, że są
serwerem, z którym się połączyły, czy wszystkie te, których HELO
nie pokrywa się z odwzorowaniem na nazwę w DNS?
Jeśli wariant drugi, to raczej nie odważyłbym się czegoś takiego
zrobić. Jeśli pierwszy, to jak najbardziej.

[Lech Szychowski]

Post by -IT-
Chyba Cię źle zrozumiałem. Czy złe to takie, które udają, że są
serwerem, z którym się połączyły, czy wszystkie te, których HELO
nie pokrywa się z odwzorowaniem na nazwę w DNS?

Jest jeszcze trzecia możliwość: HELO nie jest FQDN-em
(nie ma dla niego rekordu A w DNS-ie).

[-IT-]

[Lech Szychowski]

Post by Lech Szychowski

Post by -IT-
Chyba Cię źle zrozumiałem. Czy złe to takie, które udają, że są
serwerem, z którym się połączyły, czy wszystkie te, których HELO
nie pokrywa się z odwzorowaniem na nazwę w DNS?

Jest jeszcze trzecia możliwość: HELO nie jest FQDN-em
(nie ma dla niego rekordu A w DNS-ie).

To też trochę zbyt restrykcyjne, chociaż może kiedyś się skuszę.

Można jeszcze tak:
Robale oraz spamerskie narzędzia nie zawsze dbają o to czy jest
synchronizacja sesji. Pchają od razu HELO nie czekając w ogóle
na 220. Na 101,583 połączenia SMTP od przedwczoraj 3,612 odpadło
jeszcze _przed_ HELO. Skuteczność nie jest wyjątkowa, ale i tak
warto.

Pozdrawiam

[Lech Szychowski]

Post by -IT-

Post by Lech Szychowski
Jest jeszcze trzecia możliwość: HELO nie jest FQDN-em
(nie ma dla niego rekordu A w DNS-ie).

To też trochę zbyt restrykcyjne, chociaż może kiedyś się skuszę.

Owszem, w praktyce mocno restrykcyjne - "kosi" np. wszystkie
kiepsko skonfigurowane serwery, nadające zza NAT-a/firewalla.

Z mniej strasznych w skutkach testów można polecić
sprawdzanie, czy napis, podany jako FQDN, ma w ogóle
szanse (składniowo) nim być. Też zatrzymuje sporo
spamu, a odrzuca mniej "dobrych" przesyłek.

Post by -IT-
Robale oraz spamerskie narzędzia nie zawsze dbają o to czy jest
synchronizacja sesji. Pchają od razu HELO nie czekając w ogóle
na 220. Na 101,583 połączenia SMTP od przedwczoraj 3,612 odpadło
jeszcze _przed_ HELO. Skuteczność nie jest wyjątkowa, ale i tak
warto.

"FEATURE(`greet_pause', `5000')" - odrzucone circa 2.5 tysiąca sesji
przez ostatnie 40 godzin (na jakieś 25 tysięcy sesji ogółem).

[Grzegorz Janoszka]

Post by -IT-
Chyba Cię źle zrozumiałem. Czy złe to takie, które udają, że są
serwerem, z którym się połączyły, czy wszystkie te, których HELO
nie pokrywa się z odwzorowaniem na nazwę w DNS?

Złe to takie, których HELO nie pasuje do adresu IP.

Post by -IT-
Jeśli wariant drugi, to raczej nie odważyłbym się czegoś takiego
zrobić. Jeśli pierwszy, to jak najbardziej.

No wiem, tylko że ja mam jedną opcję i ją włączam albo wyłączam :(
Teoretycznie mogę wyłapać wszystkie bepehy, interie itp i wpisać ich
adresy IP na whitelistę, ale to nie o to chodzi :(

Eh, czemu jest tylu ladminów na świecie? :)

[Lech Szychowski]

Post by Grzegorz Janoszka
Eh, czemu jest tylu ladminów na świecie? :)

Czasem bywa jeszcze gorzej: "tak, wiem, że mamy źle skonfigurowany serwer,
ale nie mogę nic z tym zrobić - takie są 'standardy korporacyjne', narzucane
nam przez centralę w <tu-wstaw-nazwę-miasta-lub-państwa> i nie wolno nam
zmienić tej konfiguracji, a na moje pytania i prośby w tej sprawie centrala
odpowiada milczeniem albo opeerem" :(

[Lech Szychowski]

Post by Grzegorz Janoszka

Post by Lech Szychowski
...bo przynajmniej FQDN, którym się przedstawia, istnieje.

No i? Co z tego, że istnieje, skoro to nie ten? :)

A to już inna para kaloszy; nawet domena się nie zgadza...

[Dominik 'Rathann' Mierzejewski]

Date: Wed, 16 Jun 2004 10:41:52 +0000 (UTC)
From: Grzegorz Janoszka

On Wed, 16 Jun 2004 10:20:48 +0000 (UTC) I had a dream that Dominik

Post by Dominik 'Rathann' Mierzejewski

Post by Grzegorz Janoszka
Czy ktoś testował takie coś u siebie?

smtpd_recipient_restrictions =
reject_invalid_hostname,
reject_non_fqdn_hostname,
reject_unknown_hostname,

I nie masz skarg, że maile np. z bph.pl i kilku innych (wyglądających na
ważne) domen nie przychodzą?

Widać moi użytkownicy nie korespondują z takimi. ;)
Zresztą codziennie przeglądam raporty MTA i wyłapuję podejrzane hosty.

R.

[-IT-]

[Dominik 'Rathann' Mierzejewski]

Post by Dominik 'Rathann' Mierzejewski

Post by Grzegorz Janoszka
Czy nie wiecie, czy jakiś MTA przedstawia się docelową domeną?

Podobno klient Mozilli wysyła w HELO nazwę domeny adresu, który
podajesz we From:. Ale nie pamiętam dokładnie, więc mogę się mylić.

Tak, ale to jest MUA. Ma tę zaletę (chociaż gdybym z niego korzystał,
to uważałbym to za wadę), że jak po EHLO zobaczy AUTH, to MUSI się
zautoryzować. Wtedy wystarczy sprawdzić HELO po autoryzacji, co zresztą
podowiedział mi ktoś nie tak dawno temu na mordpliku.

Pozdrawiam

[Grzegorz Janoszka]

Post by -IT-
zautoryzować. Wtedy wystarczy sprawdzić HELO po autoryzacji, co zresztą
podowiedział mi ktoś nie tak dawno temu na mordpliku.

A to jak user się zautoryzuje, to ja mu nie sprawdzam żadnych helo,
blacklist ani podobnych.

[-IT-]

[Grzegorz Janoszka]

Post by Grzegorz Janoszka
Czy ktoś testował takie coś u siebie?
Czy nie wiecie, czy jakiś MTA przedstawia się docelową domeną?

Ja testuję od dość dawna, ale nigdy nie widziałem MTA, który
przedstawiłby się docelową domeną. Może podawać bzdury w HELO,
ale nie aż do tego stopnia.
Zresztą skąd wiesz, że to serwer? To może być MTA + NAT w jednym,
a wtedy trudno poznać czy to był windows zza NATu czy rzeczywiście
ten serwer. Chyba, że przejrzałeś maile, które zostały zatrzymane.

Kiedy uruchomiłem sprawdzanie HELO, to sporo czasu spędziłem na
przeglądaniu logów właśnie pod kątem false-positives, ale nie znalazłem
nic. Poza tym... chyba są pewne granice tolerancji dla niepoprawnie
skonfigurowanych MTA. Można akceptować syntaktycznie niepoprawne HELO,
brak RevDNS, nie korzystać z list open relayów, ale jeśli czyjś serwer
zachowuje się jak wirusy, to bez przesady..

W komunikacie po 550 piszę tylko w czym problem i z kim się kontaktować
w tej sprawie. Listy na postmaster@ przechodzą z pominięciem ACLi.

Pozdrawiam

[Robert Święcki]

Grzegorz Janoszka napisał w

Post by Grzegorz Janoszka
Czy ktoś testował takie coś u siebie?
Czy nie wiecie, czy jakiś MTA przedstawia się docelową domeną?

Testowałem z maksymalną restrykcją, ale już po tygodniu miałem na głowie
userów. W tej chwili tylko odrzucam te, które przedstawiają się nazwą
mojego serwera (lub jego IP).

[Bartłomiej Korupczyński]

Wed, 16 Jun 2004 15:39:54 +0200, na pl.comp.mail.mta, Robert Święcki

Post by Robert Święcki
Grzegorz Janoszka napisał w

Post by Grzegorz Janoszka
Czy ktoś testował takie coś u siebie?
Czy nie wiecie, czy jakiś MTA przedstawia się docelową domeną?

Testowałem z maksymalną restrykcją, ale już po tygodniu miałem na głowie
userów. W tej chwili tylko odrzucam te, które przedstawiają się nazwą
mojego serwera (lub jego IP).

Na prywatnym systemie odrzucam:
1. to co napisałeś
2. wszystko co jest nadawane z adresów zawierających (revDNS IP nadawcy):
.adsl. .dsl. .cable. .dhcp. .dialup. .dyn. .dynamic. .ppp.
albo zaczynających się od:
adsl* dhcp* dialup* docsis* dsl* ppp* chello*

Jako bonus za nachalność:
*.comcast.net, *.rr.com

Może trochę drastyczne obostrzenia, ale z drugiej strony nikt normalny nie
stawia MTA na adresach dynamicznych, a takie głównie one są. Maszyna
prywatna, więc mogę sobie pozwolić na takie rzeczy.

Swoją drogą, sensowne mogłoby być wprowadzenie reguły, że adresy klientów
prywatnych są w jakiś sposób oznaczane (jako .ppp., .client. lub coś innego
adekwatnego), tak żeby można je było filtrować w określonych przypadkach.
Wprawdzie nie widzę szans żeby to wprowadzić w życie, ale pomysł mógłby się
w pewnym stopniu sprawdzić. Wtedy jeśli połączenia z tak oznaczonego
adresu, to albo autoryzacja albo wypad.


BK

[Piotr KUCHARSKI]

Post by Grzegorz Janoszka
Jest to świetne rozwiązanie na wirusy i spamy - 99.99% z nich źle
przedstawia się w HELO. Problem w tym, że jest trochę polskich sieci,
które wysyłają maile ze złym powitaniem, nie będę wyliczał, ale należy
do nich np. taka interia.pl (już pomijam kwestię taką, że po wysłaniu

Wyłączyłem po tygodniu. Użytkownicy się za bardzo skarżyli.

Post by Grzegorz Janoszka
A w ogóle osobną kategorią są serwery smtp, które łącząc się z
uczelnia.edu.pl do firma.com.pl wpisują HELO firma.com.pl - mam dość
sporo wpisów, z których wynika, że serwer smtp wysyłając do mnie maila
przedstawił się docelową domeną...

A to zostawiłem i działa dość dobrze. (Za wyjątkiem Mozilli, dla
której musiałem zrobić oddzielnego hacka, eh.)

p.

[Szymon Sokół]

On Wed, 16 Jun 2004 09:43:48 +0000 (UTC), Grzegorz Janoszka

Post by Grzegorz Janoszka
Czy nie wiecie, czy jakiś MTA przedstawia się docelową domeną?

MTA - chyba ten, co jest embedded w niektórych wormach :->
MUA - np. OE, AFAIR.

[Robert Święcki]

Post by Szymon Sokół

Post by Grzegorz Janoszka
Czy nie wiecie, czy jakiś MTA przedstawia się docelową domeną?

MTA - chyba ten, co jest embedded w niektórych wormach :->
MUA - np. OE, AFAIR.

Aby MUA łączył się do naszego serwera i wysyłał nam pocztę, musi być
naszym klientem. Można więc spokojnie przyjmować pocztę bez sprawdzania
ehlo od maszyn z naszych zaufanych sieci i od klientów uwierzytelnionych
względem smtpd. Resztę należałoby odrzucać.

W postfixie, o ile można przyjmować pocztę bez sprawdzania helo/ehlo z
lokalnych sieci, to nie można sprawdzić czy klient się uwierzytelnił
(sprawdzenie parametrów helo następuje przed uwierzytelnieniem).
Przydałby się pach do postfixa umożliwiający dodanie
permit_sasl_authenticated do smtpd_helo_restrictions i przesunięcie
samego procesu sprawdzania aż do próby wysłania listu (MAIL FROM).

[Szymon Sokół]

Post by Robert Święcki
W postfixie, o ile można przyjmować pocztę bez sprawdzania helo/ehlo z
lokalnych sieci, to nie można sprawdzić czy klient się uwierzytelnił
(sprawdzenie parametrów helo następuje przed uwierzytelnieniem).
Przydałby się pach do postfixa umożliwiający dodanie
permit_sasl_authenticated do smtpd_helo_restrictions i przesunięcie
samego procesu sprawdzania aż do próby wysłania listu (MAIL FROM).

Nie potrzeba do tego żadnego patcha, wystarczy umieścić odpowiedni warunek
(np. reject_invalid_hostname czy reject_non_fqdn_hostname) w regule
smtpd_recipient_restrictions, zamiast smtpd_helo_restrictions.

[Robert Święcki]

Post by Szymon Sokół

Post by Robert Święcki
W postfixie, o ile można przyjmować pocztę bez sprawdzania helo/ehlo z
lokalnych sieci, to nie można sprawdzić czy klient się uwierzytelnił
(sprawdzenie parametrów helo następuje przed uwierzytelnieniem).
Przydałby się pach do postfixa umożliwiający dodanie
permit_sasl_authenticated do smtpd_helo_restrictions i przesunięcie
samego procesu sprawdzania aż do próby wysłania listu (MAIL FROM).

Nie potrzeba do tego żadnego patcha, wystarczy umieścić odpowiedni
warunek (np. reject_invalid_hostname czy reject_non_fqdn_hostname) w
regule smtpd_recipient_restrictions, zamiast smtpd_helo_restrictions.

Ok.. tylko, że to hostname z adresu odbiorcy (RCPT TO) a nie z negocjacji
helo.

Jeżeli damy..

smtpd_helo_restrictions = permit_mynetworks,
check_helo_access hash:/etc/postfix/helo_access,permit

a w /etc/postfix/helo_access

nasza.domena.com.pl 554 Nie jestes nasza.domena.com.pl

To odrzucamy wszystko co wysyła

HELO nasza.domena.com.pl

Jak już kilka osób wspomniało, jest to niezbyt dobre bo klienci smptd
(tym, którym umożliwiamy relay) mają MUA, które robią

HELO nasza.domena.com.pl

i teraz by pozwolić im na przesyłanie poczty przez serwer musimy

1. pozwolić na relay z mynetworks
2. pozwolić na relay uwierzytelnionym

w regule smtpd_helo_restrictions

Punkt pierwszy da się zrobić, co do drugiego bez grzebanie w kodzie chyba
niezabardzo.

[Robert Święcki]

Post by Robert Święcki
Ok.. tylko, że to hostname z adresu odbiorcy (RCPT TO) a nie z
negocjacji helo.
Jeżeli damy..
smtpd_helo_restrictions = permit_mynetworks,
check_helo_access hash:/etc/postfix/helo_access,permit

Ok, masz rację ;)..

[Szymon Sokół]

Post by Robert Święcki

Post by Szymon Sokół

Post by Robert Święcki
W postfixie, o ile można przyjmować pocztę bez sprawdzania helo/ehlo z
lokalnych sieci, to nie można sprawdzić czy klient się uwierzytelnił
(sprawdzenie parametrów helo następuje przed uwierzytelnieniem).
Przydałby się pach do postfixa umożliwiający dodanie
permit_sasl_authenticated do smtpd_helo_restrictions i przesunięcie
samego procesu sprawdzania aż do próby wysłania listu (MAIL FROM).

Nie potrzeba do tego żadnego patcha, wystarczy umieścić odpowiedni
warunek (np. reject_invalid_hostname czy reject_non_fqdn_hostname) w
regule smtpd_recipient_restrictions, zamiast smtpd_helo_restrictions.

Ok.. tylko, że to hostname z adresu odbiorcy (RCPT TO) a nie z negocjacji
helo.

"Jesteś w mylnym błędzie". Przeczytałbyś sobie kiedyś dokumentację, albo
chociaż sample/smtpd.cf...

Post by Robert Święcki
Jeżeli damy..
smtpd_helo_restrictions = permit_mynetworks,
check_helo_access hash:/etc/postfix/helo_access,permit
a w /etc/postfix/helo_access
nasza.domena.com.pl 554 Nie jestes nasza.domena.com.pl
To odrzucamy wszystko co wysyła
HELO nasza.domena.com.pl
Jak już kilka osób wspomniało, jest to niezbyt dobre bo klienci smptd
(tym, którym umożliwiamy relay) mają MUA, które robią
HELO nasza.domena.com.pl
i teraz by pozwolić im na przesyłanie poczty przez serwer musimy
1. pozwolić na relay z mynetworks
2. pozwolić na relay uwierzytelnionym
w regule smtpd_helo_restrictions
Punkt pierwszy da się zrobić, co do drugiego bez grzebanie w kodzie chyba
niezabardzo.

Zero problemu. NIE DAJEMY smtpd_helo_restrictions, dajemy za to:

smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated,
check_helo_access hash:/etc/postfix/helo_access, reject_unauth_destination

i efekt jest właśnie taki, jak sobie życzysz. Naprawdę, warto czasem
przeczytać dokumentację, w miarę możności ze zrozumieniem.

[Robert Święcki]

Post by Szymon Sokół
smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated, check_helo_access
hash:/etc/postfix/helo_access, reject_unauth_destination
i efekt jest właśnie taki, jak sobie życzysz. Naprawdę, warto czasem
przeczytać dokumentację, w miarę możności ze zrozumieniem.

Skruszony, jeszcze raz przyznam Ci rację... :) nie bij.