On 2022-07-03 17:43, W. Iszkowski (EU) wrote:
Witold,
Ok, poczytałem sobie jeszcze co nieco o SPF DAMRC i DKIM – fakt
powinny być stosowane razem.
Ale jeszcze (w 2022) istnieją poradniki wyjaśniające co jest i
jak to zainstalować.
I dobrze. Takie poradniki są do wszystkiego... Niektóre
przestarzałe, inne uwzględniają najnowsze wymagania i procedury.
Wciąż przecież nowi ludzie zabierają się za nowe (dla nich) rzeczy
i natrafiają na trudności.
Powiedziane jest, że brak tej instalacji może
uniemożliwić
wysłanie poczty do dużych operatorów jak GMAIL, YAHOO, itp.
Jeżeli tak jest to dlaczego jeszcze ci mniejsi dostawcy nie mają
takiej instalacji, świadomie się odcinając od dużych pocztowców?
Niekoniecznie robią to świadomie. Powiedziałbym, że prawie zawsze
nieświadomie. A jeśli świadomie, to może dlatego, że mają swoje -
niekoniecznie godne pochwały i naśladowania - powody. Na przykład
potrzebna są dodatkowe nakłady pracy, aby ich instalacje
dostosować... A na pewności doręczania poczty ich klientów im
specjalnie nie zależy. Albo pozostawiają zadanie konfiguracji
serwera klientowi (jak zakładasz serwer pocztowy na home.pl to sam
musisz skonfigurować SPF, a jak to zrobisz źle, to ty masz
problem, nie home.pl).
Zaś ważniejszą sprawą jest DKIM. Moje serwery mogą nie mieć, jeśli
nie obsługuję niczego ważnego tj. sfałszowanie poczty dla moich
domen nie ma istotnych skutków (o ile ktoś nie użyje konta u mnie
do rozsyłania scamu na dużą skalę). natomiast ktoś "z ulicy"
zakładający konto pocztowe (nie serwer!) w home nie musi wiedzieć
wszystkiego o poczcie, a mimo to w ramach kupowanych usług
powinien mieć pewność, że ktoś próbujący się pod niego podszywać
nie będzie miał łatwo. A tak nawiasem: jeśli zostawić to wolnemu
rynkowi, to obowiązek prawny zostanie narzucony abonentom, a duzi
operatorzy już zadbają, aby odpowiednie opcje były dostępne -
/płatne/...
I teraz na naszym polskim podwórku. Czy którykolwiek z
dużych
dostawców poczty jeszcze nie ma takich instalacji dla swoich
obsługiwanych domen, narażając ich właścicieli na brak
możliwości wysyłania poczty do tych zachodnich dużych dostawców?
Wątpię – a więc pytanie , po co ich do tego zmuszać drogą ustawową?
Po to, aby zrobili to, co do nich należy: zapewnili gwarantowany
minimalny poziom bezpieczeństwa poczty. Cały czas chodzi o scam,
który staje się coraz bardziej niebezpieczny.
A jeżeli jednak trzeba ich zmuszać, to dlaczego nie
zmusza się
tych mniejszych? Przecież do rozsyłania spamu można nawet używać
swojego serwera pod biurkiem. Jeżeli to takie ważne, to wszyscy
w PL powinni się do tego wymagania zastosować?
A jak duzi się zastosują, to mniejsi pewnie też będą musieli bo
inaczej liczba dostępnych dla nich adresatów będzie bardzo
ograniczona.
Jedni tak, inni nie, na zasadzie opisanej powyżej. Ciocia i
koledzy z klasy nie piszą nic, co wymaga nie tylko szyfrowania ale
nawet 100% pewności co do pewności tożsamości nadawcy. A jak ktoś
używa konta do rzeczy poważnych, to albo weźmie płatne, albo
bezpłatne, ale u operatora zapewniającego bezpieczeństwo. Tak
długo, jak nasi rodzimi operatorzy nie są zobowiązani, Kowalski
może nie móc znaleźć odpowiedniego dostawcy (o ile w ogóle będzie
wiedział, czego musi się domagać), no przynajmniej do chwili, gdy
mu wyczyszczą konto bankowe.
Ja prze chwilą dostałem scam, niby z home.pl, idealnie naśladujący
prawdziwy. Z jednym wyjątkiem: kliknięcie w prawidłowy
(optycznie...) link przenosiło mnie na "zieloną stronę" gdzieś w
internecie. Nie próbowałem...
Ale może też być kłopot z pocztą od tych wszystkich
zagranicznych i lokalnych, który tego SPF DMARC DKIM jeszcze nie
zainstalowali (a chyba nawet na zachodzie jest takich wielu), bo
od nich poczta będzie identyfikowana jako spam do odrzucenia.
Jak mnie zablokuje Microsoft i ktoś z kontem tam nie dostaje moich
maili to to jest mój problem. Albo korespondencja z tą osoba jest
dla mnie ważna i zrobię co trzeba, aby mnie odblokowano, albo nie.
jeśli to jest wina mojego operatora (małego...) to będę go
naciskał, albo zagłosuję nogami.
Być może jeszcze wszystkiego tutaj nie czuję, może
warto jeszcze
zapytać kogoś, ale dla mnie Art.12 jest nielogiczny,
nieprecyzyjny, niekompletny lub niepotrzebny?
Nie czujesz, bo nie zajmujesz się tym (jak ja - od dwudziestu paru
lat...).
Pozdr.
W.
Wysłane z aplikacji Poczta
<https://go.microsoft.com/fwlink/?LinkId=550986> dla systemu
Windows
*Od: *Witold Rakoczy (gmail) <mailto:witold.rakoczy@gmail.com>
*Wysłano: *niedziela, 3 lipca 2022 13:32
*Do: *opinie-pti(a)lista.pti.org.pl
*Temat: *[Opinie-pti] Re: ODP: Re: Podszywanie
On 2022-07-01 18:51, W. Iszkowski (EU) wrote:
Ale dalej popierając wywód Witolda, jednak bym nie wpisywał
nazw tych mechanizmów jako obligatoryjnie wymaganych dla
dostawców poczty elektronicznej, gdyż:
- nie są to rozwiązania powszechnie akceptowane i używane,
- o ich zastosowaniu może decydować użytkownik domeny poczty
elektronicznej (nawet taki mały jak ja mający dwie takie
domeny u dużego dostawcy OVH – i nie chciałbym aby mi na
siłę wpisywano takie mechanizmy, chociaż chciałbym aby ten
dostawca lepiej je opisał (np. DMARC i DKIM nie używa).
- SPF nie jest rozwiązaniem komercyjnym, a więc nie wiadomo
jak długo będzie wspomagane, itp.
- raczej dostawcy poczty nie powinni uzależniać przyjmowania
poczty od innych dostawców (jak to czyni Gmail) od obecności
SPF.
- to powinno być zalecenie dla wszystkich dostawców, ale nie
nakaz, a raczej samoregulacja
*ABSOLUTNIE nie zgadzam się z powyższym. Wpisanie jest
niezbędne, aby ta regulacja w ogóle odniosła jakiś skutek -
inaczej będzie dalej tak, jak teraz. *W szczegółach poniżej.
- nie są to rozwiązania powszechnie akceptowane i używane,
*Mylisz się całkowicie - są to rozwiązania powszechnie znane i
używane od wielu lat: *Wikipedia:
*SPF:* On April 28, 2006, the SPF RFC
<https://en.wikipedia.org/wiki/Request_for_Comments> was
published as experimental RFC 4408. In April 2014 IETF
<https://en.wikipedia.org/wiki/IETF> published SPF in RFC 7208
as a "proposed standard".
*DKIM:* DKIM is an Internet Standard
<https://en.wikipedia.org/wiki/Internet_Standard>.^[3]
<https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail#cite_note-Crocker_Hansen_Kucherawy-3>
It is defined in RFC 6376, dated September 2011; with updates in
RFC 8301 and RFC 8463.
*DMARC:* DMARC is defined in the Internet Engineering Task Force
<https://en.wikipedia.org/wiki/Internet_Engineering_Task_Force>'s
published document RFC 7489, dated March 2015, as "Informational".
Jeśli poczytasz o historii stopniowego ich wprowadzania to
zobaczysz, ze właśnie usiłowanie zawłaszczenia przez podmioty
komercyjne standardówopóżniło wprowadzania tych rozwiązań.
- o ich zastosowaniu może decydować użytkownik domeny poczty
elektronicznej (nawet taki mały jak ja mający dwie takie domeny
u dużego dostawcy OVH – i nie chciałbym aby mi na siłę wpisywano
takie mechanizmy, chociaż chciałbym aby ten dostawca lepiej je
opisał (np. DMARC i DKIM nie używa).
J*eżeli jakiś użytkownik obsługuje swoją pocztę (czyli jest
operatorem poczty dla pewnej - np. swojej - domeny), to
oczywiście - mając świadomość konsekwencji niestosowania isę do
ogólnie przyjętych zasad - może stosować konfigurację jaką chce.
Jednak jeśli np. jego serwer będzie akceptował i rozsyłał pocztę
od niekontrlowanych nadawców, to prędzej czy póżniej zostanie
uzyty przez spamerów i zablokowany przez wszystkich operatorów
na podstawie wpisów do baz spamerów. *
Analogicznie jest w przypadku SPF. Jego brak praktycznie
wyklucza komunikację z dużymi operatorami.
*Jeżeli zlecasz obsługę swojej domeny pocztowej jakiemuś
operatorowi poczty, to albo on pozwala ci wybrać w pewnym
zakresie sposób skonfigurowania tej obsługi, albo nie - i wtedy
możesz zmienić usługodawcę.**ALE: nie widzę powodu abyś nie
chciał lepszego zabezpieczenia przed próbami kradzieży
tożsamości (podszywanie jest tym właśnie) o ile nie jesteś
spamerem lub scamerem!*
- SPF nie jest rozwiązaniem komercyjnym, a więc nie wiadomo jak
długo będzie wspomagane, itp.
*Hahaha! Wacławie, prawie cały internet działa na zasadzie
stosowania się do rozwiązań niekomercyjnych. O wadach rozwiązań
kmercyjnych nie chcę tu dyskutować, ale ta przesłanka
zdecydowanie działa w przeciwną niż mówisz stronę!*
- raczej dostawcy poczty nie powinni uzależniać przyjmowania
poczty od innych dostawców (jak to czyni Gmail) od obecności SPF.
*Jakieś sposoby sprawdzania uprawnień do wysyłania poczty w
imieniu dysponenta domeny pocztowej chyba trzeba stosować,
nieprawdaż? W końcu cała sprawa dotyczy ograniczenia podszywania
się. To dysponent domeny powinien wskazywać, kto ma prawo
oznaczać wysyłane emaile jako nadane z adresu w tej domenie. Na
tym polega ochrona. *
- to powinno być zalecenie dla wszystkich dostawców, ale nie
nakaz, a raczej samoregulacja
*To JEST samoregulacja. Niestety, samoregulacja w świecie, w
którym "duży może więcej" działa tak, jak działa. Przykładem
jest niestosowanie się Gmaila do standardów autentykacji przy
nawiązaywaniu połączeń z serwerem poczty, wskutek czego
Thunderbird _musiał zmienić na niezgodne ze standardem (RFC)
algorytmy autentykacji._*
*_Nakaz w proponowanej ustawie ustala po prostu minimum wymagań
wobec operatora jeśli idzie o dbałość o uniemozliwianie
podszywania się, po prostu dość wysoki wspólny mianownik dla
operatorów poczty. Każdy operator nie podlegający tej regulacji
będzie mógł sobie - tak, jak sobie tego życzysz - stosowac się
lub nie stosować do tych wymagań. Zaletą przymuszającego
działania ustawy jest spowodowanie, że duzi operatorzy nie będą
mogli (oszczędzając sobie kosztów) ignorować zasad, a te trzy
mechanizmy w dodatku trudnią im "patrzenie przez palce" na
płacących użytkowników, ktorzy spamują na potęgę, psując im tym
samym biznes. Za to zmniejszając ilość śmieci, które
otrzymujesz..._*
*_W.R._*