Braindead postmaster, avagy a "Sender Verification Callout" csodája...

Web, mail, IRC, IM, hálózatok

Kezdem azzal, hogy egy régi ügyfelemnél telepítettem egy új TP-LINK 1043ND-s WiFi router-t...
Az eszköz szuperül működik, mindent beállítottam.

Találtam benne egy lehetőséget, hogy adott időpontokban küldje el a naplót egy e-mail címre...
Szuper! Kipróbáljuk! :D

Meg kellett adni a feladót, a címzettet, az SMTP szervert, a portot, + opcionálisan az azonosító adatokat.Ok.

1. próba:

Feladónak beállítottam egy a nálam hosztolt domainjükbe tartozó hamis e-mail címet, címzettnek az én saját e-mail címemet (ami ugyanitt van hosztolva), és SMTP-nek a saját szerverünket.
Azaz a feladó és a címzett is "egy helyen lakik"...
Jött a teszt levél, de sajnos a router IP címe, pont benne volt a spamhaus.org listájában... :(

2. próba:
Próbáltam átállítani a 465-ös portra a küldést és jelszavas azonosítást belőni, de a router nem képes SSL-re... :(

3. próba:
Beállítottam a szolgáltató SMTP szerverét, normál 25-ös portos küldéssel...
Meglepetésemre egy kapcsolat jött be a saját szerveremre az ISP SMTP szerverétől ilyen feladó formátumban: mail.ÜGYFÉL_SMTP_SZERVER_NEVE.hu-1358469449-testing@FELADÓ_DOMAINJE.hu
Ezt természetesen a nálunk üzemelő postgrey szépen visszautasította... :(

4. próba:
Feladónak egy freemail-es e-mail címet állítottam be és működött !!! :D

Igazából a google barátunk segítségével rábukkantam a "Sender Verification Callout" csodára... Nem sok jót írtak.
A szolgáltató saját fórumán is panaszkodtak páran arra, hogy nem tudnak levelet küldeni/fogadni...

Írások, amik elmondják, miért hülyeség: Itt és itt

Valahol azt olvastam, hogy ez a szolgáltató Magyarországon az ötödik legnagyobb...

Van valakinek ötlete ennek "feature-nek" a kiküszöbölésére?

( janoszen v | 2013. 01. 18., p – 19:03 )

A "Sender Verification Callout" egy Exim feature, amely annyit tesz, hogy a MAIL FROM-ban szereplo mailcimet megprobalja egy visszafele kapcsolattal ellenorizni. Ennek elso sorban az a szerepe, hogy SMTP auth nelkuli levelek eseten ellenorizze a feladot. Manapsag viszont tok baromsag ennek a szuronek a hasznalata.

Namost, nem egeszen ertem, hogy Te mit szeretnel, ha ADSL vonalrol szeretnel autentikacio nelkul a vilagba leveleket kuldozgetni, akkor azt surgosen felejtsd el. Egyeb esetben a smarthost szolgaltato rendszergazdajaval kellene elbeszelgetni, hogy miert beb*szva konfiguralta a mailszervert. Esetleg elmagyarazni neki, hogyan is mukodik az Exim.

Alternativakent esetleg olyan szolgaltatoval beszelgetni, akinel van a mailszerverehez erto szakember. Vagy akar hasznalhatnatok a sajat mailszervereteket is.

A feature leírását én is megtaláltam... Szerintem is baromság a használata.

Az ADSL vonalról sajnos nem tudok azonosítással küldeni leveleket, mert az eszköz nem képes rá... Ahogy írtam, már megpróbáltam a saját szerveremre irányítani közvetlenül a leveleket...

Az ISP-vel meg úgy tudok beszélgetni, mint a /dev/null-al...

A probléma jelenleg megoldott, vagy inkább úgy mondanám, hogy át van verve az ISP exim-je...
De ez nem lehet végleges megoldás.

Hogy egyértelműsítsem, hogy mit szeretnék: Változó IP címről küldeni saját magamnak levelet. Olyan eszközről, amelyik nem ismeri az SSL titkosítást. Maga a levél nem kell hogy titkosan jöjjön át...
Ennyit.

--
Debian Linux rulez... :D

Nem fog menni, ugyanis ha van olyan szerver, ami kellően sok IP-ről azonosítás nélkül enged be relayezesre levelet, azt előbb-utóbb spamelésre fogják használni. A szolgáltató ebből a szempontból elég merész.

Három megoldás van:

1. Nyitsz random porton egy SMTP szervert, ami egyetlen egy mailcímre hajlandó levelet fogadni/továbbítani.

2. Veszel egy SMTP Auth-képes eszközt.

3. Indítasz egy olyan SMTP szervert, smi pl. egy DynDNS forward lookuppal nezi meg, hogy az adott IP jogosult-e levelet küldeni.

Ezek közül az elsőt tudnám jó szívvel ajánlani.

+1: Tegyél rá *WRT firmwaret.

+2: Használj syslogot mail helyett.

Az ISP-t én nem merésznek hívnám, hanem hülyének...

1. Működhet egy csomó hackelés árán...

2. Eszköz most lett cserélve, és ez csak egy feature, ami nem szükséges.

3. Akkor már inkább nézem az ISP tartományait...

+1. A mostani fw is megfelel. + 90 km távolságból nem frissítenék rá... :D

+2. Most ez van... Ezt kell szeretni :D

+3. Nekem nem a router-rel van bajom, hanem az ISP-vel... Pontosabban a Sender Verification Callout hülyeséggel... A Posfix-emet szeretném felokosítani, hogy ha ilyennel találkozik, akkor ne küldje Postgrey-be a kapcsolatot...

--
Debian Linux rulez... :D

Nem, neked azzal van problémád, hogy van egy ISP-d aki eleve állat módon konfigurálta fel az SMTP szerverét, ami Neked éppenséggel feature, de normális ISP ilyet nem csinál.

Egyébként megnéztem, nekem is ilyen eszközöm van és tud usernévvel / jelszóval autentikálni, szóval simán használhatod saját mail szerverrel:

Firmware Version: 3.13.12 Build 120405 Rel.33996n
Hardware Version: WR1043ND v1 00000000

Az ISP-nél érvényes felhasználónevet és jelszót nem tudok... :D Na jó, elkérhetném az ismerősét, de akkor inkább a saját szerveremen azonosítanám... Nálam csak SSL után van azonosítás... Ezt viszont nem tudja... Legalábbis nekem nem jött össze vele... Te próbáltad?
--
Debian Linux rulez... :D

( sibike | 2013. 01. 20., v – 19:45 )

Feladónak beállítottam egy a nálam hosztolt domainjükbe tartozó hamis e-mail címet, címzettnek az én saját e-mail címemet (ami ugyanitt van hosztolva), és SMTP-nek a saját szerverünket.

A feladó+címzett kombinációra nem tudsz felvenni egy whitelist bejegyzést az MTA/Spamszűrő pároson?

Nem szívesen venném ki az rbl listákat ilyen esetekre sem... De ötletnek nem rossz...
Végülis most működik, de nem ilyen áron akartam...

Én a szolgáltatója által létrehozott kapcsolatot akarom felismertetni, és ilyen esetekben szeretném kihagyni a postgrey-t... Mert az dobja el a kapcsolatot.
--
Debian Linux rulez... :D

Szerintem bőven elég a valódi SMTP MTA-kat IP cím szerint fehérlistázni.
A greylisting egyedüli érteme ugyanis a nem valódi SMTP MTA-ként működő küldők kiszűrése. Aki ma sikerrel próbálja újra a levélküldést, és nem egy dial-up/dsl vonalról netezik, arról kár feltételezni, hogy holnap nem pont ugyanúgy fog átjutni a greylistingen.

Szerintem kimondottan fehérlistázni a valódi SMTP MTA-kat nem kell, hiszen:
1. Nem kicsi munka...
2. UP-TO-DATE-nek kell lennie...
3. Egy rendesen konfigurált postgrey úgyis kialakítja a saját listáját... Hacsak nem mondjuk 1 napra állítjuk a max-age-et :D

Aki ADSL-en küld levelet ma, az holnap valószínű, hogy másik IP-ről fog jönni...
A postgrey nem az ADSL "szűrésére" van kitalálva. Mindegy neki, hogy milyen IP címről kapcsolódnak...

--
Debian Linux rulez... :D

Állj!
Nem azt mondtam, hogy "úgy általában" az MTA-kat kell fehérlistázni, hanem azt, hogy a ezt a konkrét elbaszott MTA-t a legkönnyebben úgy lehet átpasszírozni a postgrey-en, hogy felveszed fehérlistára. Persze nevezheted ezt "rendesen bekonfigurálom a postgrey-t" tevékenységnek is, az eredménynek annak kell lennie, hogy a postgrey megtanulja erről az MTA-ról, hogy őt nem kell greylistingelnie.

(Igen, látom az orbitális hacket, amit csináltál rá, azt hiszem, hogy a szükségesnél néhányszor több CPU ciklust pöfögtetsz el ennek az MTA-nak a kedvéért...)