On 2022-07-04 16:25, Andrzej Szczerba wrote:
Szanowni Panowie,
Moim zdaniem, należy też wziąć pod uwagę uwarunkowania rynkowe.
Ja np. mam BARDZO stary serwer mailowy (działa już 15 lat) z
systemem Linux’owym już nie supportowanym.
Wdrożenie mechanizmów SPF DAMRC oraz DIKIM wymaga zakupu nowej
maszyny oraz nowszych wersji softu: OS’a, posfix’a i dovecot’a.
Czyli KOSZTY!
*Radzę zacząć od poczytania o tym. *
SPF wymaga tylko skonfigurowania rekordów DNS. Nic więcej.
Sprawdzenia dokonują inne serwery. Więc jakie koszty???
I SPF jest jedynym elementem absolutnie niezbędnym. Resztę można
mieć albo nie.
Jakie koszty? Konkretnie. System operacyjny? Nie. Oprogramowanie
pocztowe? Nie.
Nowa maszyna? Być może tak, jeśli jest tak stara, że postawienie
nowszej wersji systemu operacyjnego wymaga powiększenia zasobów
(bardzo mało prawdopodobne). Ale jeśli tak jest, to *stary, nie
aktualizowany system nie zapewnia bezpieczeństwa* (na przykład
problem z wersją TLS, pomijając dziesiątki podatności ) i *nie
powinien być używany*.
Ja sam mam kilkunastoletni serwer pocztowy i żadnego problemu z SPF.
Utrzymuję około setki kont mailowych: pracownicy,
współpracownicy oraz klienci.
Taki serwer da się postawić na RaspberryPi i jednym dysku SSD.
Więc praktycznie prawie każdy stary laptop go uciągnie ;-) Nie
żebym to doradzał, ale nie potrafię sobie wyobrazić maszyny tak
starej, aby nie dało się na niej postawić serwera poczty takiej
wielkości.
Jeśli chodzi o e-mail to uwarunkowanie jest takie, że mamy
wielość małych serwerów. Dla ich właścicieli podniesienie
poprzeczki to będzie nieraz całkiem spory wydatek. Znam takich
co mają w domu małą maszynę, jedno stałe IP i już mają serwer
mailowy dla siebie i rodziny.
Nie rozumiem, co ma jedno do drugiego. Ustawienie SPF nie wymaga
żadnych nakładów.
Jest oczywiście kilku dużych providerów (Google,
Yahoo,
Hotmail, itd. itp.). Dla nich podniesienie poprzeczki — to
będzie naganianie im klientów.
Przepraszam, ale to się dzieje nie ze względu na SPF.
Ja tego zrobić nie mogę, bo kiedyś zanalizowaliśmy
zapisy co do
praw Google’a (w tym autorskich) do materiałów składowanych na
Google’u.
Mając klienta, którym jest poważny podmiot publiczny (np.
centralna instytucja państwowa), który w umowie ma zastrzeżoną
nie tylko niejawność materiałów ale również prawo własności
względem nawet notatek roboczych, nikt — kto zważa na takie
aspekty — nie pozwoli sobie użyć konta pocztowego na gmail’u. Po
prostu prawa Google’a do takich materiałów kłócą się z zapisami
w umowach z podmiotami publicznymi. Tu jest b. dużo do zrobienia
dla prawników — choć wątpię czy są w stanie zrozumieć o co
chodzi — nie ogarniają nawet co to jest podpis elektroniczny,
vide polska ustawa o podpisie elektronicznym.
No, jeśli ma się instytucję państwową jako klienta i stary serwer
- nie gwarantujący bezpieczeństwa (bo jeśli jest upgrade'owany
systematycznie, to z SPF i DKIM nie ma prawa być problemów), to
faktycznie scam i mail address spoofing może być najmniejszym
problemem.
Dlatego poczta winna działać bez tych mechanizmów (w
tym SPF
DMRC i DIKIM). Być może te mechanizmy powinny być wprowadzone
przy transporcie maili pomiędzy dużymi operatorami (np. od 256
aktywnych skrzynek mailowych).
Przecież właśnie ten projekt to zakłada. Prywatny mały serwer nie
musi miec tego wszystkiego... Niestety, wiara w wielkie problemy z
SPF i DKIM to woda na młyn przestepców. Niestety, kierowanie się
obiegowymi stereotypami właśnie im pomaga. I "Wielkim" też.
*Zdecydowanie odrzucam całą tą argumentację, jako nie opartą na
faktach.**
*
Pozdr.
W.Rakoczy
*From:* Witold Rakoczy (gmail)
<witold.rakoczy(a)gmail.com>
*Sent:* Sunday, July 3, 2022 9:06 PM
*To:* opinie-pti(a)lista.pti.org.pl
*Subject:* [Opinie-pti] Re: ODP: Re: ODP: Re: Podszywanie
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._*