Re: revDNS dla SDI

Autor: marekmSPAM_at_amelek.gda.pl
Data: Fri 27 Sep 2002 - 09:49:31 MET DST


Lukasz Trabinski <lukasz_at_lt.wsisiz.edu.pl> wrote:
: Myślę, że są małe szanse na zmianę polityki dotyczącej revDNS dla klientów
: SDI.

Też tak myślałem, ale skoro od niedawna da się dla DSL...
Domyślnie jest *.internetdsl.tpnet.pl - ale można to zmienić.

Szanse małe, ale myślę, że warto próbować. Z odpowiedzi którą
otrzymałem wynikałoby, że problem jest bardziej regulaminowy niż
techniczny - więc próbuję dotrzeć do tych, co ustalają regulamin.

: Po pierwsze, ktoś w tpnet musiałby się tym stale zajmować[1], podejrzewam,
: że chętnych na zmianę byłoby bardzo dużo.

Zajmować się mogą ci sami ludzie, którzy to robią dla POLPAK-u i DSL.

Czy chętnych będzie aż tak dużo? Trzeba mieć domenę (nazwa revDNS musi
zamieniać się z powrotem na ten sam IP) i w ogóle wiedzieć z czym to
się je - przypuszczam, że jak ktoś ma open proxy, to jest mu zazwyczaj
obojętne jaki ma revDNS ;). Osobiście nie mam nic przeciwko pobieraniu
(rozsądnej) dodatkowej opłaty za revDNS dla SDI. Przypuszczam, że tych
chętnych może być wtedy co najwyżej kilka procent...

Przy okazji - mogą w ten sposób poprawić niedopatrzenie: regulamin
SDI nic nie mówi o możliwości odłączenia za nadużycia (w DSL już to
jest). Zmiana revDNS mogłaby wymagać podpisania przy okazji stosownego
aneksu do umowy - też osobiście nie miałbym nic przeciwko temu...

: Po drugie zmiana wprowadziłaby pewien choas w siecie, w tej chwili na
: przykład, będąc administratorem serwera NEWS w dosyć prosty sposób można
: ustawlić politykę dostępu dla użytkowników SDI. Oczywiście politykę dostępu

Ale dla użytkowników POLPAK-u czy DSL (tych którzy ustawią sobie revDNS)
i tak trzeba dawać dostęp po IP - dlaczego SDI miałoby się wyróżniać
w taki sposób? Połączenie z Internetem jak każde inne, z tą różnicą
że dostępne (tam, gdzie ludziom w TPSA się chciało stworzyć owe słynne
i poszukiwane "możliwości techniczne") za rozsądną cenę...

: Po trzecie, skąd pewność, że inni providerzy nie zaczną blokować dostępu
: na podstawie numerów IP wyciągniętch z RIPE, wtedy inna nazwa revDNS na
: niewiele ci się zda.

Oni postrzegają domenę sdi.tpnet.pl jako duże źródło spamu, gdzie
trudno zidentyfikować winnego bo każdy ma standardową nazwę revDNS,
więc prościej blokować całość. Procentowo pewnie tyle samo spamu
jest z POLPAK-u, tyle że tam to przychodzi z różnych domen, a tutaj
z jednej - 0,1% z kilkudziesięciu tysięcy to już niestety dużo.
Bardziej efekt psychologiczny - tu jedno duże źródło spamu, a tu
wiele małych. Oczywiście, jak zablokują całość *.pl to zostanie
tylko przeniesienie się do innego kraju...

: Po czwarte, nie sądze aby TPSA zmieniła politykę w usłudze, z której jak
: wiadomo powoli próbuje się wycofać.

Raczej przenoszą do mniejszych miejscowości, gdzie chyba DSL się im
nie opłaca. W normalnej sytuacji (gdybym mógł wybierać - taniej SDI
bez revDNS, albo drożej DSL z revDNS), nie byłoby problemu, ale w danym
miejscu jest dostępne tylko albo jedno, albo drugie, albo nic...

: Moja propozycja jest taka, abyś w miarę swoich możliwości załatwił sobie u
: znajomego admina lub u kogoś kto zna admina :) "Smart relaying"

Mam taką możliwość (korzystam z tylko dla redhat.com), ale to nie to
samo - jak są jakieś problemy z dostarczaniem poczty, to nie widzę tego
w swoich logach, tylko dopiero po jakimś czasie kiedy dostanę zwrot...

: poczty, lub nawet jakiś tunel. (wadą tunelu jest strata prędkości, w związku z
: narzutem na dodatkowe nagłówki IP). Byc może, któryś ISP sprzedaje taką usługę
: za niewielką opłatę?

W ogóle mógłbym za niewielką opłatą mieć u jakiegoś ISP konto pocztowe
i www, zamiast SDI mieć 45/80 i mieć dużo wolnego czasu, nie musząc
zajmować się własnym serwerem ;). Ale mam taki kaprys, że sam chcę być
sobie adminem swojego własnego ISP - wystarczy mi podłączenie do sieci,
nie potrzebuję "darmowych" skrzynek i stron www dodawanych do Neo+...
SDI jest pod tym względem prawie tym, co trzeba - z wyjątkiem braku
revDNS, który też do niedawna nie był dla mnie problemem.

Marek



To archiwum zostało wygenerowane przez hypermail 2.1.7 : Wed 19 May 2004 - 18:01:30 MET DST