Lányok is kockulhatnak

GeekLány



Mit tegyél a spammerrel? 1

Posted on augusztus 02, 2011 by Varsányi Martina

Először is, tedd tiltó listára. Ha másképp nem megy, a komplett domaint.  Nekem pl. hiába küldesz citromailes levelet, ha ismerlek, akkor is a devnullban landol, nem lesz kivétel (persze senkit se ismerek, aki citromailt használna, de ez más kérdés). Ez máris sokat dob az ember kedvén.

Ha viszont másoknak is kedvében akarsz járni, akkor a következőket teheted:

Ha magyar a spammer, akkor olvasd el a JogIQ oldalán a Mit lehet tenni, ha spamet kapunk? bejegyzést.

Ha idegen nyelvű spammerről van szó, akkor ún. feketelistára rakhatod őt pl. a Spamhaus projektnek elküldve.  Ezt a feketelistát számos mailszerver használja a világban, és ezzel már a spam továbbküldését is meg tudják akadályozni.

Másoknak kedvében járni meg azért jó, mert akkor ők is a kedvedben járnak és Te is kevesebb spamet kapsz.

Te mit teszel a spammel?

Nesze neked spammer 0

Posted on október 22, 2009 by Varsányi Martina

Változás történt a spam bejelentésében, az ügyfélkapun keresztül lehet bejelentést tenni, ha kéretlen leveleket kapunk.

Míg az Index szerint macerásabb lett a bejelentés, szerintem sokkal korrektebb módja, hogy a bejelentést módja már nem noname, akármilyen ingyenes emailcímről.

Az ügyfélkapus megoldás több szempontból is üdvözlésre méltó.

Egyfelől egy központi helyen tudok ügyeket intézni, most már spammert is (fel)jelenteni, ez pedig az, amiért már évek óta sír a netes társadalom. (Lásd a németek hivatalosan elismert online petíciókat is tudnak szervezni az ügyfélkapujukon keresztül.)

Másfelől komolyan lehet venni állampolgári kötelességünket és jelenteni a szabálytalanságot. Tessék végre felfogni, hogy a névtelen vádaskodás nem vezet sehova.

Hogyan kövessük az emailek útvonalát? 0

Posted on június 15, 2009 by Varsányi Martina


Mindennapos dolognak számít, ha a csomagküldő szolgálatnál megnézzük, hogy milyen útvonalon jutott el a csomag a címzetthez. Kevésbé ismert tény, hogy ugyanezt megtehetjük a beérkező emailjeinkkel is.

Minden email rendelkezik egy fejléccel, amit a legtöbb email olvasó program elrejt előlünk. Ebben a fejlécben szerepelnek az eredeti feladót azonosító IP cím, valamint azok a szerverek, melyen a levél keresztül haladt az útján.

Miért jó ez?

Ha nem vagyunk biztosak egy email eredetében, akkor az email header megtekintésével lehetünk biztosak abban, hogy valóban a feladóként szereplő személy, cég küldte a levelet.

Az email fejléc elérésé programonként változik, ráadásul néha el is rejtik a menüt a kíváncsi olvasó elöl. Mégis érdemes rászánni az időt, hogy egyszer megtaláljuk.

Mit látunk a headerben?

Példaként azt a levelet mutatom meg, amit a Fehér Házból kaptam. Vajon tényleg a Fehér Házból jött? Lássuk a fejlécet!

Return-Path: <info114@service.govdelivery.com>
X-Original-To: chris@localhost
Delivered-To: chris@localhost.mine.nu
Received: from ***** (localhost [127.0.0.1])
by ***** (Postfix) with ESMTP id 85253BCA
for <chris@localhost>; Wed, 13 May 2009
     20:20:12 +0200 (CEST)
X-Original-To: info@blogvilag.hu
Delivered-To: chris@blogvilag.hu
Received: from ***** [**.214.110.112]
by ***** with POP3 (fetchmail-6.3.9-rc2)
for <chris@localhost> (single-drop); Wed,
     13 May 2009 20:20:12 +0200 (CEST)
Received: from service.govdelivery.com
     (smailer1.service.govdelivery.com [208.42.190.242])
by ***** (Postfix) with ESMTP id 56ACA14D0004
for <info@blogvilag.hu>; Wed, 13 May 2009
     19:17:31 +0000 (UTC)
Received: from service.govdelivery.com ([10.10.20.242])
by service.govdelivery.com (StrongMail
     Enterprise 4.1.1.4(4.1.1.4-47689));
     Wed, 13 May 2009 14:17:09 -0500
X-VirtualServerGroup: Default
X-MailingID: 1215495828::480211::1001::PRD-BUL-480211
     ::info@blogvilag.hu::121436
X-SMHeaderMap: mid="X-MailingID"
X-Destination-ID: info@blogvilag.hu
X-SMFBL: aW5mb0BibG9ndmlsYWcuaHU=
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative;
boundary="----=_NextPart_001_AEA6_74B0DC51.19495CFF"
x-subscriber: Gj7UxKFz94g7NmXt3tChryV7S96KbNUJ
X-AccountCode: USEOPWH
X-Mailer: bulletin
X-TokenInfo-OBO: 32233
Errors-To: info114@service.govdelivery.com
Reply-To: President Barack Obama
     <president@messages.whitehouse.gov>
MIME-Version: 1.0
Message-ID: <1242242104804.1225234857.2030401332.
     bulletin.tomcat5@prod-batch1.visi.gdi>
Subject: Health care news worth sharing
Date: Wed, 13 May 2009 14:17:09 -0500
To: info@blogvilag.hu
From: President Barack Obama
     <president@messages.whitehouse.gov>

Keressük meg az első “Recieved: from” sort. Ez a localhoston futó SMTP szerver címe. Felismerhető a 127.0.0.1-es IP-ről.

A második “Recieved: from” pedig annak az SMTP szervernek a címe, amelyik kiszolgálja a levélcímünket. Ha nem Linux/Solaris alól nézed a leveleket, akkor valószínűleg ez lesz az első bejegyzés.

A példában a harmadik “Recieved: from“, a

Received: from service.govdelivery.com
     (smailer1.service.govdelivery.com [208.42.190.242])

az az SMTP szerver, amin keresztül a levél elindult hozzánk. Kis kereséssel megtudhatjuk, hogy a http://www.govdelivery.com/ URL a Goverment-To-Citizen Communication Solutions-t rejti

*SMTP szerver: Simple Mail Transport Protocol Ezek a szerverek felelősek azért, hogy a levél eljusson a címzethez.

Valamivel lejjebb van egy olyan sor, hogy

X-Mailer: bulletin

Ez mutatja meg, hogy milyen levelező eszközzel küldték a levelet. Ha pl. ezt látjuk:

X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.10

akkor nem kell zseninek lenni ahhoz, hogy kitaláljuk, ezt a Yahoo Mail-ről küldték. A példa esetében a bulletin arra utal, hogy egy tömeges levélküldést lehetővé tévő programmal küldték el.

Received: from service.govdelivery.com
     (smailer1.service.govdelivery.com [208.42.190.242])

Received: from service.govdelivery.com ([10.10.20.242])
by service.govdelivery.com (StrongMail
     Enterprise 4.1.1.4(4.1.1.4-47689));
     Wed, 13 May 2009 14:17:09 -0500

Ezekből a sorokból azonban sok mást is megtudhatunk. A levelet útjára indító szerver az internetről a 208.42.190.242-es IP címen található meg, míg a belső hálón a 10.10.20.242 a neve. A levél leküldésére a StrongMail megvalósítását használták.

Ha akarjuk, akkor kíváncsiságból megnézhetjük a DomainTools-zal, hogy az 208.42.190.242 IP címhez tartozó gép helyileg Minnesota államban van.

Ha ennél egyszerűbben akarjuk megjeleníteni a küldő gép adatait, akkor másoljuk be a fejlécet a Email Trace online szolgáltatáshoz, ami még azt is megmondja nekünk, hogy a kérdéses gép konkrétan Shakopee városban van.

Mikor van rá szükség?

Mindez akkor hasznos, ha kétséges a levél forrása. Pl. a PayPal biztos, hogy nem Kínából vagy Chiléből akar veled kapcsolatba lépni. Az se valószínű, hogy az OTP külföldről küldené neked a jelszókérő levelet. Ha rendszeresen egy adott országból kizárólag spameket kapsz, akkor letilthatod azt az országot is.

Spamszűrés Postfix-szal Solarison 0

Posted on június 01, 2009 by Varsányi Martina

Miután meguntam, hogy egy “politikai” párt listájára felkerültem, beizzítottam a Solarison a spamszűrést. Nekem a postfix kezeli a leveleimet, ami a legjobb, az IBM által szponzorált SMTP szerver a piacon (véleményünk szerint), ráadásul könnyen konfigurálható.

Az SMTP szerverre pedig azért van szükség, mert a fetchmail (ami leszedi a leveleket) nem a mailboxba pakol közvetlenül, hanem a localhost-os smtp-nek dobja át, ami nálam a postfix.

A leveleket domain vagy teljes emailcím alapján lehet kezelni. A beállításokat a /etc/postfix/access alatt kell elvégezni.

Whitelist (engedélyezett levelek listája):

trusted_friend@example.com OK
grandpa_george@some_domain.org OK

Ezt a beállítást nem használom (nem itt), minden levelet szívesen látok. Kivéve… amiket nem szeretünk, azokat az alábbi beállítások valamelyikével lehet kiszűrni:

# REJECT drops the message with a default error message.
#
hostile_domain.com REJECT

# Any 5xx code means a fatal error, and the mail client should not try again.
# Here we’ll make a specific rejection message to send as part of the
# bounce message, rather than the default REJECT version.
#
ex-girlfriend@some_host.net 554 Get a life and move on.

# Code 4xx means that the client should retry later, it’s a non-fatal error.
#
busy-mailinglist@example.org 450 Sorry, we’re performing an upgrade of our mailinglist software, be back on Thursday.

Ahhoz, hogy mindez működjön, be kell állítani a /etc/postfix/main.cf-ben, hogy

smtpd_sender_restrictions =
     check_sender_access dbm:/etc/postfix/access

utana pedig máris kiadhatjuk a

postmap /etc/postfix/access

parancsot.

A beállítások eddig a pontig linuxon és Solarison is ugyanazok. A következő lépésként újra kell indítani a postfix szolgáltatást, amit Solarison a

svcadm restart postfix

paranccsal tehetünk meg, linuxon pedig a

/etc/init.d/postfix restart

parancsot kell ehhez kiadni.

A masszív, aggresszív spammereket kézzel viszem fel.

A “maradék” szűrésére a spamassassint használom, abban van whitelist, spamlist, illetve bevezettem a “graylist”-et, amibe azok a levelek kerülnek, amiket a spamassassin nem fogott meg (valószínűleg nem spam), de még nem vettem fel a whitelistra.

A különböző kódok értelmezésében az alábbi táblázat segíthet:

Code Meaning
554 Transaction failed (This is the default for messages using Postfix’ REJECT syntax.)
550 Requested action not taken: mailbox unavailable.(Good for sending permanent errors.)
450 Requested mail action not taken: mailbox unavailable. (Good for sending temporary errors.)

Via Filtering E-Mail with Postfix and Procmail



↑ Top