Amavis - spam küldőnek kiértesítés

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

Sziasztok!

A legnagyobb tiltakozásom ellenére az egyik cég azt kéri, állítsam be nekik, hogy amennyiben az amavisd-new (spamassassinnal) spam-et érzékel, akkor a spam küldőjét - mármint, ha valós a cím -, akkor értesítse ki a rendszer. Tudom, hogy egy tonna redundáns adattal tolom meg a netet ezzel, de egy spamnek azonosított megrendelésen nagyon sok pénzt buktak. Persze van a cégnél egy ember, aki megkapja a spam-jelentéseket, de ő sem káptalan, hogy minden tökéletesen átvizsgálja; van más dolga is. Ezért úgy döntött a cég vezetése, hogy minden spamnek azonosított levélről értesítsük a feladót és természetesen továbbra is menjen értesítés a cég egyik alkalmazottjának.
Sajnos nem találtam megoldást rá. Van esetleg valaki, aki tudna segíteni?

Előre is köszönöm.

  • 2632 megtekintés

( Oregon (nem ellenőrzött) | 2006. 12. 16., szo – 11:28 )

hasonlo okok miatt en az alabbit alkalmazom:

- ha spamnek minositem a levelet, csak es kizarolag fejlec modositast hajtok vegre (*****SPAM*****)
- a usereknek van SPAM konyvtara amibe belekerul a level
- a user spam konyvtarabol n ido mulva torlodik a level.
Mindez mar user szinten van allitva a user altal. Persze igenyelt nemi okitast, de megeri, mert igy a user dont a leveleirol, hogy hogyan kezeli. Eddig egy kollegano panaszkodott, de o meg nem volt batanitva leven, hogy 100km-re van tolem.

Szabaly cca ez:
1. level atrakasa SPAM konyvtarba
2. level megjelolese olvasottnak (hogy ne legyen zavaro)
3. SPAM konyvtar ervenyessege 1 het, ami utan torlodnek a levelek.

( dszabo | 2006. 12. 16., szo – 11:56 )

#$warnspamsender = 1; # (defaults to false (undef))

amit küldjön:
# $notify_spam_sender_templ = read_text('/var/amavis/notify_spam_sender.txt');

( bra | 2006. 12. 16., szo – 12:48 )

Végezd az ellenőrzést még az SMTP párbeszéd lezárása előtt (data fázisban) és ha spam, amit eldobnál, szimplán utasítsd el 550-nel.

De fontos, hogy ne az SMTP kapcsolat lezáródása után ellenőrizz, és próbáld a feladó (igazi vagy hamis) címére visszaküldeni a levelet, mert így generász felesleges nagy forgalmat.

A jó megoldás az, hogy még az SMTP kapcsolat közben ellenőrzöl, és egyszerűen a kapcsolat végén, ha spam, nem fogadod el a levelet, olyan hibával, amiből kiderül, hogy SPAM-na gondoltad.

Így te nem fogsz egyetlen levelet sem küldeni, nem fogod leterhelni a rendszert, a másik oldalon viszont a küldő értesül arról, hogy a levele nem ment el.

Egyébként érdemes lenne az adott céggel megértetni, hogy az SMTP protokol nem a biztonságos és garantált levelezésről szól, tehát ha nincs az email mellett még valami (fax, telefon, stb), akkor spamszűrés nélkül is lutri.

Nincs rá garancia, hogy a nagy megrendelés email tényleg meg fog érkezni. Ha meg a megrendelő nem kérdez rá telefonon, akkor megette a fene az egészet.

G

Nem vicces. Nekem is ez volt az első gondolatom, hogy megkérem írja be a szerverei ip cimet, hogy feketelistára tegyem.

Majd amikor az ügyfelei levelezoszerveren hasznalt dnsbl tömegesen blokkolja a szerverüket mert hamisított from-ra küld vissza levelet spam tartalommal (ha csatolva van), akkor megtanulja hogy mitől veszít levelet igazán...

Én is ezt csinálom. Viszont néhány marha cégen sajna ez sem segít. Most volt egy emberke, akinek a cége többször akart már küldeni az "én" cégemnek és persze nem sikerült. (Kaptak egy client rejectet host not found-al, mivel nincs rendesen konfigurálva a DNS-ük)
A vége az lett, hogy az "én" cégem tulajdonosa hívott fel, hogy el akarják vinni a megbízást, mert mégiscsak felháborító, hogy 1 hónapja nem tudnak az "én" cégemnek küldeni levelet. ...és csináljak valamit.
Csináltam. Beszéltem az ügyvezetővel, aki adta a rendszergazdát ...és végül felraktam őket a kivétel listára. (/etc/postfix/client.lst :))) Na ez magyarország 2006-ban.

...és még majdnem engem rúgnak ki.

Van azonban ennek egy kellemetlen mellekhatasa: a spammer addig tudja csurni-csavarni a levelet, amig atmegy a szurodon. En egy norveg, Barracuda-t hasznalo illetonek kuldtem at ugy 2-jara egy levelet, hogy az 1. alkalommal visszadobta, es az SA-ja frankon beleirta, hogy miert adott oly sok pontot. Ezutan mar gyerekjatek volt ugy modositani a levelet, hogy atmenjen. Javasoltam is neki, terjen at valami true Bayesian szurore, az SA-alapu Barracudat meg dobja ki.

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

( Aewyn | 2006. 12. 16., szo – 22:29 )

annyira örülök neki, h ez a kérdés kábé havonta újra és újra és és újra felmerül, és mindig pont ugyanúgy végződik.

ezért mostan azt szeretném kérni, h minden spamnotifájer rendszergazdát azonnal végezzenek ki.

lehetőleg lassan és fájdalmasan.

köszönöm.

Hidd el, hogy eddig nem volt ilyen, és ha figyelmesen elolvastad volna, mit írtam, akkor tudhatnád, hogy minden akaratom ellenére kérik ezt tőlem.

Amire viszont föntebb céloztatok, hogy visszajelzést csak valós e-mailcímre küldjön a rendszer, megcsinálom.

gee írta:
A jó megoldás az, hogy még az SMTP kapcsolat közben ellenőrzöl, és egyszerűen a kapcsolat végén, ha spam, nem fogadod el a levelet, olyan hibával, amiből kiderül, hogy SPAM-na gondoltad.

Ok. Ezt gyarkorlatban hol kell elkövetni?

Hopsz megakadtam.

Ha a $warnspamsender = 1; -et beállítom, akkor bizony visszaküldi a fejlécet és a levél tartalmát a SPAM jellegével együtt. Ez nem jó megoldás.

Szépen bekonfigoltam a http://www.ijs.si/software/amavisd/README.customize.txt alapján a /var/amavis/notify_spam_sender.txt fájlt, és kivettem a kommentet:
$notify_spam_sender_templ = read_text('/var/amavis/notify_spam_sender.txt');

A $warnspamsender = 1 nagy ívben tesz a $notify_spam_sender_templ-re. Nem tudom, hogy van-e közvetlen összefüggés vagy nincs.

ha figyelmesen elolvastad volna, mit írtam, akkor tudhatnád, hogy minden akaratom ellenére kérik ezt tőlem.

tőlem pedig azt kérik -akaratom ellenére-, h likvidáljak minden ilyen rendszergazdát.

hogy visszajelzést csak valós e-mailcímre küldjön a rendszer

az a radioaktív szpemvisszajelzés, amit visszaküldesz, az jó eséllyel _valós_ címre fog érkezni, és ott annak rendje és módja szerint a szükséges pusztítást végre is fogja hajtani.

persze ez nem az a cím lesz, amely; de ez azért ne nagyon zavarjon :(

( PMC | 2008. 02. 14., cs – 00:33 )

Van egy elvi etikai kérdésem: egy céges MTA-t kell beállítani, és nem tudom hogy a vírusos levelekkel mit etikus csinálni?
D_DISCARD
D_REJECT
D_PASS

amavis-new-t használok.

Szóval mit etikus beállítani?

- $final_virus_destiny = ?
- $final_banned_destiny = ?
- $final_spam_destiny = D_PASS
- $final_bad_header_destiny = D_PASS