Pont erről van szó.

Legális? Biztos nem. Még ha cégnek elvileg lehet is legálisan SPAM-et küldeni, akkor is maga a címlista megszerzés módja kifogásolható. Gyanítom egy főiskolás „hekker”-től megvásárolt, netről összegyűjtött listáról van szó. Ez a tevékenység viszont egyértelműen törvénybe ütközik.

Ahogy mélyül a válság itthon úgy szaporodik azoknak a kétségbeesett vállalkozásoknak a száma, akik bedőlnek a „vásárolt legális magyar e-mail címlista” baromságnak azaz e-mailes DM kampányba kezdenek. Ezzel még így nem is volna baj, mert mint megtanultam a mondást: „mindenki úgy szopatja magát ahogy akarja”. Csak hogy ez engem is kezd már zavarni.

Nap mint nap telenyomják olyan SPAM-el a postafiókom, amit soha sem kértem, ráadásul úgy is olvasás nélkül törlöm. A levél végén persze elegánsan hivatkoznak, hogy ez mitől is legális és persze mellékelik a kamu leiratkozó linket is, ami tapasztalataim szerint inkább egy „megerősítem, hogy olvastam, és feliratkozom mindenre” opciót rejt. Tapasztalatom szerint különben ezek a „legális címlisták” jellemzöen két csoportra oszthatók, az info@cegesdomain.hu jellegűek és a weboldalakról összevadászott címeket tartalmazók.

Ez eddig nem nagy cucc, miért is írok róla? Elkeztem építeni egy antiDM adatbázist, amibe ezeknek a cégeknek illetve a levelek kiküldését végrehajtó csatlósaik adatait gyüjtöm. Az adatbázis alkalmas arra, hogy e-mail szerver feketelistájaként használjuk. Mióta beindult ez a kis gyüjtögetés, már nem bosszúság egy újabb bejövő SPAM, mivel szépen gyarapítja a kis listánkat. Akár meg is köszönhetnénk, hogy önként feliratkoznak :). Mióta használom a céges postafiókjaimon, hetente alig esik be egy-két DM e-mail.

A blokklistát hamarosan a közösség számára is hozzáférhetővé teszem.

Többször tapasztaltam a fenti hibát, (jelenleg) legfrissebb TB esetén is – 17.0. A megoldás a következő:

Eszközök >Beállítások > Speciális fül >
Konfigurációszerkesztő.  Ezeket a kulcsokat kell átállítani:
„mail.imap.fetch_by_chunks”
„mail.server.default.fetch_by_chunks”

„False”-ra kell állítani. (az első kulcs nálam nem is létezett)

Thunderbird restart után még ugyan nem lesz jó, de ha jobbklikkelünk a „Beérkezett üzenetek” mappára, ott tulajdonságok.
A megjelenő panelen „Mappa javítása” megoldja a problémát.

Remélem másnak is segítek vele.

Ma 2 órám ment el azzal, hogy helyrehozzak egy érdekes „hibát”.

Adott egy szerver legyen „A”, amit később erőforrás híján „B”-re cserélünk. Viszonylag könnyű dolgunk van ESXi esetén: átdugdossuk a HDD-ket (ebben az esetben elég volt csak ennyit tenni), átdugjuk a hypervisor USB-flasht és kész, mindenki örül.

Persze. Addíg amíg elszünkbe nem jut újra elővenni „A” gépet, hogy újra használjuk a hálózaton (azonos L2). Ekkor ugyanis komoly meglepetésben lesz részünk. Ugyanis a hypervisor „szépen” megjegyezte azt a MAC címet amivel első alkalommal dolga volt, így MAC cím ütközés lesz a hálózaton.

A megoldás, resetelni kell konzolon a management hálózat beállításait. Ez ciki ha a gép távol van, mint az én esetemben, de szerencsére mostanság hülye szokásunk, hogy minden szerverbe kérünk DRAC kártyát 😉

Vonatkozó VmWare KB cikk: Itt

Linux virtuális géphez kellett septében még egy disket hozzáadnom reboot nélkül.
A vSphere clientben összeklikkelgettem, majd ezt kellett beverni Linuxnak, hogy használni is tudjam azonnal az új lemezt. (SCSI hot add)

echo "- - -" > /sys/class/scsi_host/host#/scan
fdisk -l