SPF na pld-linux.org (było: libgadu.spec)

[Tomasz Pala]

On Mon, Apr 05, 2010 at 20:21:08 +0200, Jan Rękorajski wrote:

>> Dokładnie tak samo jak wszystkie zaproponowane alternatywy - oto mój
>> wniosek, szkoda że nie raczyłeś się ustosunkować.
> 
> Cyt.:
>> > Natomiast takie DKIM nic nie psuje, a daje dużo wyższy poziom
>> > uwierzytelnienia.
> 
> innymi słowy jest compatible.

Fakt, nie jest to dokładna kopia tej sytuacji; mojego DKIM-a po prostu
nikt nie zweryfikuje i tym samym nie mam ani problemów, ani
zabezpieczenia;)

> Bzdurą jest, że SPF pozwala Frankowi zakładać, że mail wysłał szef.
> Franek patrzy na "From:" (który może być z dupy), a nie na envelope From
> sprawdzany przez SPF (który też, w ograniczonym zakresie, nie konieczne
> musi być prawdziwy).

A to współczesne czytniki nie weryfikują nigdzie From-bez-dwukropka
(tzn. 1 linijki) jako źródła? A to ja nie wiedziałem, myślałem że
technika posunęła się na tyle do przodu w tak niebezpiecznych czasach.

> SPF został wymyślony do zwalczania "abuserki" - spam, phishing
> czy inne fałszywki, dla mnie i tak to wszystko jest spamem,
> rożnica jedynie dialektyczna.

Fałszywki mają tę niemiłą cechę, że ciężko zdenerwowanemu klientowi
wytłumaczyć, że to nie nasz system jest dziurawy i pozwolił komuś
'włamać się na konto prezesa', tylko protokół SMTP jest taki
sprytny, że potrafi wysłać coś 'z maila' nie korzytając w ogóle z
serwera dostawcy. SPF zajmuje się przypadkami znajdującymi się poza
naszą jurysdykcją.

> Czytałem. Problem polega na tym że SPF jest "sprzedawany" jako super
> zabezpieczenie przed spamem.

Cóż...

>> A ten argument jest absurdalny - co z tego, że spamer podpisze swoją
>> buyviagraonline.yu SPF, skoro ani przyjmujący system pocztowy tego NIE
>> WYMAGA, ani system antyspamowy nie punktuje dodatnio zgodności?
> 
> Jak nie wymaga, jak wymaga? ;) Jakby nie wymagał to nie byłaby potrzebna
> gimnastyka z SRS.

Chcesz mi wmówić, że jeśli domena nie będzie miała rekordu TXT, to
poczta z niej nie dojdzie? No ciekawe ciekawe. SRS jest potrzebny _jeśli_
domena ma ustawiony SPF. Nikt nie nakazuje spamerom ustawiania tego dla
własnych domen, równie dobrze mogą wysyłać z 'niezabezpieczonych' i nie
będą z tego tytułu mieli żadnych nieprzyjemności ani zysków (chyba że
jakieś Mądre Inaczej systemy antyspamowe punktują dodatnio za zgodność).

> A dla spamera/abusera brak punktów ujemnych = punkty dodatnie :)

Przecież za domenę bez TXT też dostaje się punktów tyle samo
(okrągłe 0), więc nie ma różnicy pomiędzy spamerską domeną bez TXT a
posiadającą rekordy. Chyba że spamerzy chcą zabezpieczać swoje domeny,
żeby pod nich nikt się nie podszywał;)

>> >> "SPF offers a whitelist, not a blacklist."
>> >> Z pewnością każdy właściciel domeny chciałby blacklistować ręcznie całą
>> >> Azję i USA, oczywiście.
>> 
>> Nie wiem, czy to też uważasz za bzdurę, ale domyślam się że tak.
> 
> Ehem, bo weryfikujący SPF blacklistują na podstawie whitelisty.

Czekaj, bo chyba się nie wyspałem - czy tam wyżej to jest sugestia tego,
że lepiej byłoby, gdyby właściciel domeny wpisywał gdzieś informacje,
skąd maile pochodzące rzekomo od niego NIE mają się pojawiać? Czyli
żebym np. do swojego DNS-a robił codziennie import jakiegoś RBL-a i
mówił 'pod tymi adresami nie wierzcie, że to ja nadaję'?
...ale to się dubluje z RBL-ami właśnie. Nie wiem jak taka blacklista
miałaby wyglądać.

>> Dla mnie jako właściciela domeny zabezpieczonej SPF jak najbardziej
>> jest. Nie interesują mnie forwardery - SRS to jest ich problem.
> 
> To że twoi klienci nie dostaną poczty (uczciwej, nie spamu), to już jest
> Twój problem.

Chyba nie do końca rozumiesz, w którą stronę działa SPF.
Moi klienci co najwyżej NIE WYŚLĄ poczty z pominięciem mojego serwera
SMTP. Na odebranie mimo złego SPF mają szanse, bo za to mail dostanie
tylko jakieś ujemne punkty w antyspamie.

>> > Natomiast takie DKIM nic nie psuje, a daje dużo wyższy poziom
>> > uwierzytelnienia.
>> 
>> Tylko szkoda, że nie jest używane.
> 
> gmail.com, Twój przykładowy. No i DKIM nic nie psuje.

No to sobie kiedyś zrobię. Jak będę miał czas, pewnie koło emerytury.
Chyba że wcześniej postfix dorobi się tego jako opcji on/off, bo nie
chciałbym popsuć ludziom poczty, która działa i problemów nie zgłaszają.

> Rozumiem, innymi słowy "twoja poczta kliencie to nie mój problem".
> Trzeba było tak od razu. 

W pewnym momencie trzeba przestać podchodzić do tematu z matematyczną
analizą i dowodzeniem jego poprawności. Gdy pojawiają się problemy -
wtedy się reaguje. Nadgorliwość jest gorsza od faszyzmu. Jak klient miał
problem z kontrahentem z Chin, to trzeba było dla niego wyłączać
znacznie więcej.

> Bo to jest ich problem, a wycięcie portu 25 to było zamiecenie problemu
> pod dywan.

Nie, było bardzo skutecznym ograniczeniem problemu (ostatni PLNOG).
Klient domowy nie potrzebuje 25 portu, od tego jest zgodnie z RFC port
465 (SSL) lub 587 (opcjonalnie TLS). Taki gmail nigdy nie był dostępny
na 25 porcie dla klienta.

> No, ale to, na szczęście, nie mój problem, ja klientem TPSA
> nie jestem ;)

Gdybyś był i miał serwer pocztowy, to żaden problem tę blokadę sobie
wyłączyć. Jednak praktyka pokazuje, że mało kto tego potrzebuje
(webmaile i jasne instrukcje na największych polskich pocztach).

>> znane) rozwiązanie. Tam również masa ludzi nie rozumiała, czym się różni
>> submission od SMTP i krzyczeli tylko, że spamerzy zmienią port (no i jak
>> sobie gównianie tego submission zrobią, to będą dalej spamowani, ale ja
>> będę miał spokój, bo tamtędy niezautoryzowane mi nie przejdą).
> 
> To się będą musieli postarać żeby go gównianie zrobić :)
> Mój postfix to "by default" nie chciał bez AUTH po submission rozmawiać.

Nie chcesz pewnie wiedzieć, ale Ci ludzie proponowali włączanie tej
usługi poprzez ...przekierowanie 587 portu na 25 :)

> A, tak przy okazji, jak zachowałby się Twój system jakby zobaczył
> rekord SPF typu "v=spf1 +all"? Przez ciekawość pytam.

Nie mam pojęcia, ale możesz taką dać i coś mi wysłać, to zajrzę w logi:)

-- 
Tomasz Pala <gotar w pld-linux.org>