Postfix beállítása spammerek ellen, ha lehetséges.

Linux-haladó

Sziasztok!

Van egy saját postfix-os levelező szerverünk, amely kezeli a valaki@domain.hu (ez egy kitalált cím, ténylegesen nem ez!) alakú leveleinket.
A fő problémánk az, hogy a nevünkben küldenek más gépekről (pl. romániából, koreából, ...) spam leveleket.
Tehát nem a mi levelező szerverünk küldi a spamet, hanem más gépek, csak a feladónál a mi email címünk van megadva.
Úgy tudom, hogy a normálisabb levelező szerverek már rákérdeznek (talán HELO-val), hogy van-e a megadott e-mail cím az adott domain-hez, amelyről küldeni akarnak. A postfix szerverünket úgy szeretném beállítani, hogy, ha adott gépekről akarnak küldeni (pl. a levelező szerverünk v. inviteles smtp szerver, ...), akkor a valaki@domain.hu-ra mondja azt, hogy van ilyen, ha más gépről, akkor pedig mondja azt, hogy nincs ilyen.
Tud valaki erre megoldást?

  • 4963 megtekintés

( csabyka v | 2008. 04. 15., k – 16:25 )

Ez nekem most nem tiszta.
Azt szeretnéd elérni, hogy csak bizonyos gépeknek (levelező szerveretek, inviteles smtp) -re működjön a helo ? Tehát ha az éngépem akarna helózni(és nincs benne a listában), akkor ne menjen ?
szerintem mutass postfix configot és segítünk


--ha magyar MAC-et akarsz--

Valóban nem nagyon érthető, hogy mit is szeretnék.
Próbálom részletezni.
Van a mi levelező szerverünk, legyen a neve A.
Vannak külső gépek K1, K2, ...
Ha tetszőleges K1 gép akar küldeni levelet nekünk (A-nak), tehát mi vagyunk a címzettek, akkor, menjen a HELO.
Ha K1 akar levelet küldeni K2-nek (a mi nevünkben), akkor, ha K2 helózik, akkor ne menjen.
(ahol K1 nem A és nem a megbízható gépek)

Azért is írtam feltételesen, mert nem tudom, hogy van-e erre megoldás.
Azt sem tudom, hogy HELO-nál milyen infok mennek át.

XXs-Apple:~ csy$ telnet papa.xxxx.hu 25
Trying 193.XXX.XXX.XX...
Connected to papa.xxxx.hu.
Escape character is '^]'.
220 papa.xxxx.hu ESMTP Postfix (Debian/GNU). All SPAM is Reported!
ehlo papa.xxxx.hu
250-papa.xxxx.hu
250-PIPELINING
250-SIZE 20480000
250-VRFY
250-ETRN
250-AUTH PLAIN LOGIN CRAM-MD5 DIGEST-MD5
250-AUTH=PLAIN LOGIN CRAM-MD5 DIGEST-MD5
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

ezek az infók.

de en ezeket a beallitasokat hasznalom postfixnál.
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, reject_invalid_hostname
smtpd_recipient_restrictions = permit_mynetworks,
reject_unauth_pipelining,
permit_sasl_authenticated,
reject_unauth_destination,
reject_non_fqdn_recipient,
reject_non_fqdn_hostname,
reject_non_fqdn_sender,
reject_invalid_hostname,
reject_rbl_client list.dsbl.org,
reject_rbl_client bl.spamcop.net,
reject_rbl_client sbl-xbl.spamhaus.org,
reject_rbl_client sbl.spamhaus.org,
reject_rbl_client cbl.abuseat.org,
reject_rbl_client dnsbl.sorbs.net,
reject_rbl_client dnsbl.njabl.org,
reject_rbl_client combined.njabl.org,
reject_rbl_client opm.blitzed.org,
reject_rhsbl_client blackhole.securitysage.com,
reject_rhsbl_sender blackhole.securitysage.com,
permit
smtpd_delay_reject = yes


--ha magyar MAC-et akarsz--

Anno próbálgattam dinamikus IP-ről küldözgetni leveleket, és úgy vettem észre, hogy kb. a "nagy" levelezőszerverek fele egyből visszautasít (SpamHaus), viszont másik fele csont nélkül elfogad, köztük a GMail-lel, amin nagyon csodálkoztam. Bezzeg a Freemail, Citromail elvetette a leveleimet. Azóta inkább az ISP-m szerverét használom küldésre, és alig van gond.

De ez mellékszál, csak megjegyzés volt :)
--
http://www.open-st.eu

Az, hogy egy ip cím dinamikus-e vagy statikus, eldönthetetlen kérdés. A világban nem egy nem kettő olyan címlistát tartanak karban igazi seggfejek, ahol teljesen véletlenszerűen és indok nélkül dől el, hogy dinamikus-e egy cím.

Az én címeimet is felrakták egy-két ilyen listára, és a lista karbantartója jobban elhitte egy senkiházi amcsinak a putriból, hogy a cím dinamikus, mint nekem, a whoisba bejegyzett adminnak, hogy nem az.

Úgyhogy nem csak azokról van meg a véleményem, akik ilyen listákat állítanak össze, hanem azokról is, akik ezt felhasználják. Miért nem keresnek meg egy jósnőt, hogy az mondja már meg az üveggömbjéből, hogy milyen az a cím? Pontosabb válaszokat kapnának, mint ilyen listákról.

Ha valaki most megsértődött rám, azt jól tette.

A jövendölés amit a játékfilmeken például üveggömbbel, vagy kártyalapokkal művelnek. A jóslás jóval korábbi keletű, mára főleg a távol keleten maradt hagyomány és valóban működik, ugyanis nem arról szól, hogy mi vár rád később, lesz-e nagy házad, meg sok pénzed, hanem a jelen feladataival foglalkozik és a jelenre ad megoldást. A "mit tegyek most?"-ra ad választ. Sok esetben eszköz se kell hozzá. De időnként látni, hogy csontokkal, kaviccsal, pénzérmével jósol valaki. A neve is innen ered. A jót keresi, nem a jövőt. A részletek az ősi, titkos tanokban vannak. Amik a közhiedelemmel ellentétben nem azért voltak soha sem titkosak, mert nem tudhatta meg akárki, hanem azért, mert nem volt egyszerű feldolgozni se lelkileg, se szellemileg.
--
unix -- több, mint kód. filozófia.
Life is feudal

A HELO/EHLO nagyon nem erre való. Az egy kötelező eleme az SMTP-sessionnek. Részletesen: RFC 2821. FQDN-t vagy IP-t küld, de ez nem mindig releváns információ. Lásd dinamikus IP, NAT. Amire te gondolhatsz, az a VRFY vagy EXPN, de ezek általában tiltva vannak, nem igen használják.

Szóba jöhet az SPF/Sender ID, de ezek szerveroldali támogatást igényelnek, tehát a példádban szereplő K1 által a K2-n futó MTA-nak küldött levelet csak K2 tudja ellenőrizni az általad megadott DNS-információk alapján. Ha K2 nem SPF-képes, akkor nem működik ez a dolog. Tehát lényegében csak az SPF-képes MTA-t használó K2-t véded meg attól, hogy a a te nevedben hamisított feladójú levelet kapjanak.

( ScOut3R | 2008. 04. 15., k – 17:35 )

Az SPF rekord körül kellene nézelődni. Igaz ez sem 100%, de ha egy fogadó SMTP szerver ellnőrzi az SPF rekordot és hamisított spamet kapn látszólag tőletek, akkor eldobja a levelet.

( Mik v | 2008. 04. 15., k – 20:58 )

SPF-et nem nagyon kellene eröltetni:
http://www.hbone.hu/HBONE-ules-2007/2007-hbone-spf.pdf
13. oldaltól kezd érdekes lenni, persze az egészet sem árt elolvasni.

main.cf:
smtpd_recipient_restrictions =
permit mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
check_sender_access hash:/etc/postfix/access/sender_access,
stb,

sender_access tartalma:
xxx.hu 550 Mail claims to be from XXX.HU yet isn't.

Ha valaki a saját hálózatodon kívülről a te domaineddel küld e-mailt (a from-ban az xxx.hu szerepel), azt a Postfix elhajtja a ...-ba

Mik

Egyébként hasznos írás, bár nagyon sok esetben hiányzik hozzá a körítés, ami az előadás közben nyílván elhangzott. Az írásból viszont az nem derül ki, hogy mit ajánlana helyette.

Amit írtál az csak akkor működik, ha az én postfixemmel akarnak küldeni levelet.
(Ez egyébként be van állítva nálunk is, és jelenleg kívülről nem is lehet küldetni levelet, csak belülről)

domainkeys? De amint az spf, ez sincs annyira elterjedve. Halozati (smtp) szinten egyszeruen nem tudod magad megbizhatoan megvedeni a spamtol. Ezek nem kepesek lekezelni pl. azt a helyzetet, amikor egy bizonyos gep kuld spamet is, meg jo levelet is (pl. web hosting, php mail() fuggveny). Arrol nem is szolva, hogy a helo, visszakonnektalok xy-hoz, stb. ellenorzes rontja a teljesitmenyedet, es sok fals pozitiv hibat okozhat, ld. amikor 2 admin anyazik egymassal, hogy a masik miert nem tudja normalisan beallitani a helo-t, stb. Ha _megbizhato_ spamszurest akarsz, akkor a levelet kell vizsgalni.

ASK Me No Questions, I'll Tell You No Lies

"Amit írtál az csak akkor működik, ha az én postfixemmel akarnak küldeni levelet."

Nemegészen. Akkor működik, ha a Te Postfixeddel akarsz levelet _fogadni_ a Te domaineddel. Az ellen semmit nem tudsz tenni, hogy egy spammer valahol a nagyvilágban a Te címeiddel küldjön levelet... K1 K2-nek, ha akar küld levelet, olyan címmel amilyennel akar. És ezzel nem tudsz mit kezdeni.

Mi van SPF helyett? Néhány évtized türelem, amíg az smtp helyett nem lesz más... DomainKeys használható.

"Az ellen semmit nem tudsz tenni, hogy egy spammer valahol a nagyvilágban a Te címeiddel küldjön levelet... K1 K2-nek, ha akar küld levelet, olyan címmel amilyennel akar. És ezzel nem tudsz mit kezdeni."
De lehet, épp ez volt az alapkérdésem lényege.
És ahogy többen írták pl. az SPF épp erre való.
Az alapműködés lényege:
Ha K1 K2-nek levelet akar küldeni az én nevemben, akkor K2 (ha SPF-et kezeli) "megkérdezi" a levélcímhez tartozó domain-t (az én szerveremet), hogy ki küldhet ilyen leveleket, és ha azok között K1 nincs, akkor visszautasítja a levelet.

Ez igaz, amit írsz. Olyasmi ez, mint a telefon. Amíg kevés embernek volt, addig nem érte meg használni. Minél többnek van, annál jobban megéri.
Tegnap este beüzemeltem próba jelleggel az SPF-et, egyenlőre csak féloldalasan. Tehát az én levelezőszerverem is megnézi, hogy a küldő (K1) jogosan küldi-e a levelet nekem (K2).
Eddigi tapasztalat:
Nagyságrendileg kb. 400 kapcsolódás a levelező szerverhez.
Abból kb. 120 eljutott a Spam ellenőrzésig.
Ebből 56 használt SPF-et ( 3 megbukott )
Egyébként a 120-ból kb. 110 spam. :-(

Tehát kb. egy fél napos tapasztalatom (:-) azt mutatja, hogy kb. 50%-os az SPF használat.
Ez a mi levélforgalmunk alapján van és nagyon rövid idő alatt, tehát általánosítani azért nem szeretnék.

Az SPF ellenőrzés csak akkor működik, ha van SPF bejegyzés a TXT-ben. Ha nem talál bejegyzést, akkor nem is ellenőrzi azt, mint ha nem is lenne ellenőrzés. Persze van rendszergazda aki annyira elkötelezett az SPF iránt, hogy azoknak akik nem használják visszaküld egy automatikus válasz levelet, hogy állítsák be az SPF rekordot maguknak. Kaptam már én is ilyen tartalmú levelet.

3 éve használunk SPF-et, és SPF ellenőrzést is. Naponta az spf policyval 5-8000 levelet fog meg az MTA így. A levelezésben ~8000 céges postafiók vesz részt, napi ~350000 bejövő levél.
Fontos viszont egy megfelelő terhelhetőségű saját DNS kiszolgálót üzembe állítani a lokális hálón, amit (amiket) az MTA is használ. Meg hát csak akkor ér valamit az SPF ha a partnerek is beállítják a domainekre.

A nagy probléma még, hogy az SPF ISP függővé teszi a felhasználót, ezért meg kell hagyni a lehetőséget a domain tulajdonosoknak az SPF beállítására. Nagy cégeknél ez nyilván nem probléma, mert otthonról nem kell céges levelet küldözgetni.

( bazso | 2008. 04. 16., sze – 12:33 )

A problémám hasonló, csak még egy csavar van rajta. Az én nevemben (létező, SPF-fel ellenőrizhető cím) küldenek egy spam-et egy nem létező címre, amit így a mailer daemon visszadob az én postafiókomba, magyarul némi mailer daemon fejléccel én kapom meg a spam-et.
Erre eddig egy megoldást találtam: az ironport cimkézi a kiküldött leveleket, és csak olyam mailer daemon-os levelet enged vissza, ami rajta keresztül ment ki. Postfix-re hasonló címkéző módszert ismertek?

Üdv,
BaZso

Igen! After-queue content filter a neve. A postfix (imho) nem tud onmagatol ilyet, de miert ne irhatna hozza barki egy ilyen 3rd party cuccot? De szerintem jobban jarsz egy tartalomszurovel, ami akkor is felismeri a spamet, ha az bounce-kent jott... Ilyen van egy temerdek postfix-hez.

ASK Me No Questions, I'll Tell You No Lies

Egy malomban őrlünk. :-)
Ha a te nevedben küldenek és a te levelező szervered SPF-fel ellenőrizhető, akkor a nemlétező postafiók levelező szervere (ha SPF képes), akkor SPF ellenőrzés után eldobja a levelet, ahelyett, hogy neked visszaküldené.
De szerintem az sem jobb, ha létező címre megy és a te nevedben rendelnek 30 plazma tévét :-)
A másik irány amiért jó az SPF, hogy ha kapsz egy levelet valakitől, akkor tudhatod, hogy tényleg tőle jött (legalábbis a levelező szerverétől). Ez pl. banki leveleknél nem hátrány, bár ők pont nem szoktak leveleket küldözgetni :-)

( szogi v | 2008. 05. 25., v – 21:44 )

A blackhole.securitysage.com ma reggeltol kezdve mindent blokkol, erdemes minel elobb eltavolitani az ellenorzesek kozul.

Spammerek sokszor azzal ugyeskednek, hogy a spamet rogton a backup mailserverre kuldik, a primary mx-et kihagyva, azt remelve, hogy a backup mx-en kevesbe eros a spam szures, aztan az atcsuszott spamet maga a backup mx kuldi el az elsodleges szervernek. A masodlagos szerveren ezert hasznalok blacklisteket, hogy nyugodtan szurje csak meg a sok spammert, legitim level eleg keves megy oda, mert az elsodleges mx majdnem mindig online.

( tmms v | 2009. 10. 18., v – 14:33 )

Úgy tudom php-ban megírt kóddal bármilyen címről lehet küldeni, akár nemlétezőről is.

Úgy mondták és tesztelték is rajtam :)
--
Home: Ubuntu 8.04 LTS
Server: Debian Lenny

( mljava | 2009. 10. 27., k – 09:32 )

Hasonló problémával küzdök én is. Nálunk így fest a dolog:

Leveleink a szolgáltatónknál landolnak fetchmail segítségével hozom el onnét.
Szóval: fetchmail->postfix->cyrus

A szolgáltatónk végez spam szűrést azokat a leveleket meg is jelöli így én az tudom kezelni viszont:
Sok az olyan levél amit ők nem tekintenek spamnek viszont azok. Jelenleg a Thunderbird van tele üzenetszűrő beállításokkal és ezt szeretném kiváltani, hogy a szerver végezze a szűrést, de ne dobja el a levelet hanem külön mappába gyűjtse.

Sajnos ezek olyan levelek amiket csak tartalomra lehet szűrni. A feladó mindig más a tartalmak szoktak hasonlóak lenni.

Szeretnék tippet kérni, hogy ezek ellen hogyan lehet védekezni,

A spam-eket a szolgáltatóm szűri. én lényegében egy listát készítenék a feladókról és abból keresném ki hogy kell-e az a levél vagy sem.

És hasonló tartalmi szűrést is szeretnék. Ha bizonyos mondatok vagy szókapcsolatok szerepelnek a levélben akkor az menjen vissza a feladónak vagy KÜLDŐNEK, hogy szabálytalan tartalmú levél.

Bocs, rosszul fogalmaztam.

Amit szeretnék 1:
készítek egy listát különböző e-mail címekkel.
Ha jön egy levél és a feladó szerepel ebben a listában akkor az megy a kukába vagy az admin felhasználó spam könytárába.

Amit szeretnék 2:
Különböző tartalmú leveleket nem szeretnék elfogadni és erről szeretném értesíteni a küldőt vagy feladót.
Az utóbbi sikerült is. Pl. trágár szóra a szerver válasza: "Nem megfelelő tartalom"
Ez akkor működik, ha én küldöm.

Viszont, ha hasonló levelet kapok akkor nem megy vissza az értesítés és a levelet sem kapom meg. Az rendbe is van, hogy nem kapom meg. Mivel a szolgáltatómtól hozom a leveleket fetchmail segítségével így a fethmail kapja az üzenetet:
...
fetchmail[26202]: SMTP error 550 5.7.1 Nem megfelelo tartalom
...
És a feladó már nem tud semmit.

Remélem sikerül jól fogalmaznom.

Miert, milyen megfontolasbol akarod visszakuldeni? Szerinted kit fog a visszakuldott 'Ne spammelje le' uzeneted erdekelni? Btw. a fetchmail (annyira nem ismerem, de) (fixme) szerintem nem fog semmit sem visszakuldeni...

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta