Telekom dinamikus IP Spamhaus

 ( kovanorby | 2017. október 9., hétfő - 11:59 )

Sziasztok! Mostanában folyton olyan IP-ket kapok itthon a telekomtól, ami spamhaus feketelistás, pl: 81.183.96.0/19 is listed on the Policy Block List (PBL)

Emiatt thunderbird levelezőben, nem tudok kiküldeni leveleket bizonyos helyekre, mert: Hiba történt a levél küldése közben. A levelezőkiszolgáló válasza:
https://www.spamhaus.org/query/ip/81.183.127.

Mit lehetne ezzel kezdeni? Fix IP-t nem lehet otthonra kérni, szóval mi lehet még a megoldás?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

szerintem egy VPS-el olcsóbban jársz, mint egy FIX IP-vel...

és vpn? 1000/200-hoz elég nagy vps kéne..

Mihez? Hogy elkuldjel egy levelet? Vagy mit is szeretnel csinalni?

Nem, a VPN-en a teljes adatforgalom átmegy, és nem fogom minden egyes email kiküldésnél ki-be kapcsolgatni a VPN-t. Az elég kényelmetlen.

És miért kéne egyáltalán VPN? Hol jön a képbe?

A kérdező kissé fogalomzavarban szenved.
Egyébként az alábbi opciók lehetnek VPS-el:
1) mint fentebb írták: mail relay (auth után természetesen)
2) ha egy VPN-t egyszerűbben be tud állítani, akkor megoldás lehet (csak) az SMTP forgalmat (azaz az SMTP szervert) ide route-olni

ps: ha a forrásIP van listázva - és az belekerül a fejlécbe - ezzel is kaphat bőven elég pontot a kipontozódáshoz, nem?

Tévedsz, azt hittem a VPS-t használjam VPN-hez és boldogság, ez is egy megoldás.

Az smtp szerver végez ellenőrzést úgy néz ki, mivel már a küldési folyamat akad el, nem pedig visszapattan

igen, az is egy megoldás, hogy a VPS-re felteszel egy VPN szervert, és minden forgalmat arra tolsz - csak felesleges (és ugye "lassú" is lesz).

Ha csak az SMTP irányú forgalmat tereled a VPN-re, akkor nyertél.
Ha a VPS-en csinálsz magadnak egy mail relay-t (ami az internetről jövő leveleket sikeres smtp-auth nélkül eldobja, viszont a belső (értsd vpn) felől jövő leveleket kiengedi) akkor is nyertél. Ebben az esetben elfelejtheted a szolgáltó SMTP szerverét.

Szerintem ez lesz a megoldás, köszi

A VPN-en az az adatforgalom megy át, amit arrafelé route-olsz. Ha felrakod default route-nak, akkor nyilván minden arra megy át, de miért tennéd fel default route-nak?

BTW, a topicnyitó problémához szerintem nem a VPN a megoldás.

A VPS nem VPN felhuzol ra egy relay-t azt csok. Nem kell neked arra routolnod semmit sem.

Nem ertem, te nem kulso szolgaltatot hasznalsz levelkuldesre (ahol hitelesitesz)?
Egyaltalan hogy kerulsz a spamhaus latokorebe?

az smtp szerver amit használok, már az visszadob, mert látja, hogy spammer ipről akarok ráküldeni emailt

Milyen porton küldöd a levelet? Sima SMTP 25-ös vagy submission (587)?

Utóbbin IMHO nem kellene, hogy az SMTP szerver RBL ellenőrzést végezzen. Ha végez, akkor konzultálj az SMTP szerver üzemeltetőjével.

587, és végez rajta ellenőrzést úgy néz ki

És nem hitelesített smtp? Nem lehet hitelesíteni, (esetleg csak opcionális), és akkor nincs ellenőrzés?

És ha már itt tartunk, a Telekom-tól oké hozzáállás, ha ilyen IP-t ad ki? Kicsit olyan nekem, mint ha a kölcsönzőben körözés alatt álló autót adnának neked. Megkerested őket? Mi a hozzáállásuk?

csak kérdem, h a másik oldalon meg az volna a helyes hozzáállás, ha véletlen TE rakod spamlistára az IP-t akkor a havi díj többszörösét fizettetik ki veled büntetésként?

Nem is írtam nekik, igazából teljesen feleslegesnek érzem, az említett elég nagy tartomány is (/19) fullba listázva van, még ha annyira aranyosak lennének se tehetnék meg hogy akkor ezt a /19-et nem használják, mert valakinek nem tetszik.. :D

Nem a spaumhaus a hibás ebben az esetben, hanem az SMTP szolgáltatód. Ha hitelesítve küldesz levelet, akkor nem szabadna nekik IP cím alapján ellenőrizni. Nekik kell szólni, hogy a szolgáltatást (amiért gondolom fizetsz) nem tudod használni.

Nem tudom, tényleg. Mondjuk azt bizonyítani, hogy tényleg tőlem jött a spam, nehéz. Úgyhogy nem, nem volna helyes.

Ezzel semmi probléma nincsen, uis a szolgáltatónak biztosítani kell a visszakereshetőséget.
Jelen esetben - ha más nem, a spamtrap-ek által - megvan, hogy melyik ipcímről milyen időpontban küldték a levelet,
arra pedig nyakadat teheted, hogy meg tudják mondani, a forráscímet éppen melyik előfizető használta.
Még carrier-grade NAT esetén is!

Szerintem R=0 ügyfélből lényegesen több van, úgyhogy a szolgáltatók a dinamikus tartományaikat simán elengedik, nem éri meg küzdeni vele. (Látod magad előtt, ahogy az 50-60 éves Gizi nénit, Windows XP-vel felhívják, hogy ezen a porton ezt és ezt a forgalmat hagyja abba? Szerintem is reménytelen, még ha büntet is érte.) A normálisabb ISP-je annyit még tesz, hogy alapból tiltja a 25-ös portot kifelé, és a PTR-en látszik, hogy dynamic pool, aztán nagykabát.

Már eleve ott a mail relay mekkora szívás lehet... :/
--
https://naszta.hu

Authentikaltan probalsz levelet kuldeni?

Csak mert amit linkeltel ott annyira nyavajog csak:
'you need to turn on "SMTP Authentication"'

Itt havi 300 egy alap Ubuntu szerver, ami jó levelezésre kapsz fix IP-t.
Nálam egy ilyen vason fut a levelezés és a webszerver is.
https://www.arubacloud.hu/ingyenes-probaverzio.aspx

Orwell az 1984-et regénynek írta és nem használati utasításnak!