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 was published as experimental RFC 4408. In April 2014 IETF published SPF in RFC 7208 as a "proposed standard".

DKIM: DKIM is an Internet Standard.[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'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).

Jeż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.