Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Nežli popíši počáteční stav naší firemní sítě, rád bych alespoň v kostce čtenáře AbcLinuxu.cz seznámil s tím, proč si myslím, že s problémem SPAMu musíme bojovat.
Proč tedy? Asi proto, že historie SMTP (tedy protokolu zodpovědného za přenos elektronické pošty), je stará přes 20 let, kdy nikdo ani nepomyslel, že by se e-mail mohl zneužít takovýmto způsobem. I otázky, proč to ti spammeři vlastně dělají, ztrácí smysl, když si uvědomíte, že poslat někomu e-mail je zdarma - pokud pošlu někomu neznámému mail s textem "Give me some money", pravděpodobně se zasměje a mail smaže. Pokud však tento mail zašlu pár milionům nic netušících lidí, vždycky se najde nějaký pitomec, který mi zaplatí. A pokud se najde, rád podobný mail zašlu lidem zas - vždyť je to přeci zdarma a zpáteční adresa se dá krásně zfalšovat, takže tisícovky rozzlobených lidí nemají, na kom si právem vylít svoji zlost.
A právě takovou zlost jsem měl i já, když jsem musel každý den mazat desítky nevyžádaných mailů. A tak jsem začal zkoumat, jak naši firemní síť "vylepšit", abych tento neustálý tok mailů zastavil.
Jak je vidět z obrázku, konfigurace firemní sítě byla v podstatě standardní - maily z Internetu procházejí firewallem do MTA (Mail Transfer Agent - v podstatě mašina, která mail vezme, rámcově zkontroluje a pošle dál) v zóně DMZ. Tento stroj funguje jako relay agent - maily s vnitřní e-mailovou adresou tak přeposílá na vnitřní mail server na intranetu. Odtud jsou pak přímo dostupné koncovým uživatelům.
Jako MTA zde funguje osvědčený Sendmail a v interní síti MS Exchange (já tlačil Scalix, ale bohužel to neprošlo). Žádný z těchto dvou strojů problém spamu neřešil a filtrování pošty tedy zůstalo na konečných uživatelích (Thunderbird s Bayesovským filtrem).
Problémy jsme tehdy měli v podstatě dva:
U problému s generováním bounce-mailů (hlášení o nedoručitelnosti) bych se rád pozastavil, protože si jej mnoho administrátorů MTA (a sítí podobných té naší) neuvědomuje. Představme si větší společnost s doménou @example.com, která má svůj firemní mailserver na lokální síti a maily do internetu posílá a přijímá přes proxy MTA server připojený v demilitarizované zóně - tedy něco jako naše síť na obrázku výše.
Na první pohled z hlediska bezpečnosti výborné řešení, protože vnější útočník se nikdy nemůže dostat přímo na firemní mailserver. Problém ale nastává právě s generováním mail bounces, protože proxy MTA v demilitarizované zóně bude pravděpodobně konfigurován jako RELAY pro celou doménu @example.com a o existenci uživatelských účtů na koncovém mailserveru nebude mít ani tušení.
Pokud tedy přijde spam pro neexistujícího uživatele jarda@example.com, relay MTA v demilitarizované zóně jej s radostí přijme a přepošle firemnímu mailserveru. Ten jej odmítne, protože žádný mailbox pro Jardu nemá, a relay MTA v DMZ tedy musí vygenerovat mail bounce.
V normálním případě by to bylo to v pořádku (mail bounce vygenerovaný proxy MTA by dostal odesílatel a zjistil, že Jarda neexistuje). Pokud by však byla adresa odesílatele podvržená (což je u SPAMu běžný jev), bounce je doručen někomu, kdo nic takového neposílal. V horším případě doručen být nemůže a mail bounce se nám hromadí ve frontě a zbytečně zatěžuje mailserver.
Neutěšenou situaci ve firmě jsem monitoroval již dlouho a zamýšlel jsem se tedy nad možnostmi řešení - které by pokud možno neobsahovalo žádnou "černou krabici" za spousty peněz. Nejsem sice zapřísáhlým odpůrcem komerčních řešení, ale nerad se dávám všanc něčemu, do čeho nikdo nevidí. Problém jsem rozdělil na dvě části:
Problém jsem vyřešil pomocí perl skriptu, který je v pravidelných intervalech spouštěn na vnitřním mailserveru a generuje seznam platných firemních emailových adres. Tento seznam je pak pomocí TFTP stáhnut na MTA proxy stroj v zóně DMZ. MTA má pak možnost přímo v otevřeném SMTP spojení ověřit existenci adresy příjemce. Pokud neexistuje, spojení je ukončeno s chybou 550 Recipient not found. Za vygenerování mail bounce je pak zodpovědný vnější odesílatel (ať už pravý, nebo ne).
Jiným řešením by bylo zkonfigurovat LDAP podporu v Sendmailu, který by si sám mohl existenci příjemce ověřit zasláním dotazu přímo na vnitřní LDAP server, ovšem to by znamenalo jisté bezpečnostní riziko, a proto jsem zvolil cestu pomocí tftp.
Jako administrátorovi mailového serveru mi bylo jasné, že neexistuje jediná jednoduchá metoda, jak spam potlačit, a proto se obvykle kombinuje metod více. Není proto ani cílem tohoto článku představit nějakou "zázračnou" novou metodu - spíše shrnout dostupné metody a doporučit nejúčinnější.
V zásadě můžeme antispamové metody rozdělit takto:
Uveďme alespoň nejvíce užívané a nejúčinnější (dle mého názoru) metody boje s nevyžádanou poštou. Zde se omezím na řešení integrovatelné do MTA, protože koncového uživatele obtěžují nejméně. Z těchto technik jsou mi nejvíce sympatické RCPT fáze, a to ty, které pracují v úvodních fázích dialogu SMTP:
Jak už jsem říkal, nejvíce sympatické jsou mi techniky, které pracují v úvodních fázích SMTP dialogu (dále RCPT fáze). V této fázi je již známa adresa odesílatele, příjemce a stroj, od kterého zpráva přichází, ale ne tělo zprávy. Proč mi tedy přijde zajímavá?
Jaké jsou nevýhody technik v RCPT fázi:
Naše firemní MTA je realizována na Linuxu a Sendmailu, proto jsem se rozhodl o nasazení greylistingu prostřednictvím skvělého démona milter-greylist, který běží na mail proxy stroji v DMZ a je tak nejblíže zdrojům SPAMu - a může tam fungovat nejefektivněji (pokud mluvíme o realtime technikách detekce spamu, tak ty je možno aplikovat pouze na tomto stroji - na vnitřním mailserveru to už nemá smysl). Jak název připomíná, základ tohoto démona je v implementaci greylistingu, který je v mém případě prominut odesílatelům s pravým SPF podpisem nebo, těm kteří alespoň disponují podporou TLS [wikipedia, IETF.org].
Účinnost mého řešení přesahuje 90 % - a to v podstatě "zadarmo", protože nároky na CPU jsou nízké a dále není třeba nic updatovat a ani se o něco starat. Ano, nějaký spam i tak sem tam proleze, ale pořád je zde ještě možnost nasazení zmiňovaného SpamAssassinu (na který je možno démona milter-greylist také připojit), který by účinnost dále dramaticky zvýšil. Zároveň se rýsuje možnost nasazení dalších slibných technik jako P0f, DKIM a DNSRBL. Stabilita tohoto softwaru je rovněž příkladná, takže určitě mohu doporučit.
Přikládám prezentaci (ODP), kterou jsem vytvořil v rámci propagace greylistingu pro naši firmu.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Mam to doplneno spamassassinem a lokalnim blacklistem. To se osvedcilo nejvice, blacklist mam hlavne na SMTO clenu, co to neumi nastavit, a bounces mi zatezuji mailserver. Navic to mam nastaveno na vystupu jako transparentni SMTP proxy, cimz eliminuju Wirouse a jako posledni vec jaou limits v postfixu s generovani udalosti tenhle posila moc, jukni zda neni zawirovan.
Chtelo by to jeste nasledujici:
Automaticky zablokovat SPAMMera z vnitrni site, vcetne fredirectu HTTP na lokalni server s upozornenim o omezeni pripojeni.
analyzator nejhorsich SPAMMeru zvenci s tim, ze se daji primo do FW jako REJECT
analyzator nejhorsich SPAMMeru zvenci s tim, ze se daji primo do FW jako REJECTJako ze treba kvuli jedne postarsi zenske se zavirovanym pocitacem kompletne odstrihnete nejaky jiny freenet? Zajimavy pristup.
Ano, ale muselo by to být už na GW toho freenetu.To ovsem mluvite o zcela jinem navrhu hwsofta:
Automaticky zablokovat SPAMMera z vnitrni site, vcetne fredirectu HTTP na lokalni server s upozornenim o omezeni pripojeni.Je to zcela neco jineho nez se snazit donutit bandu neschopnych loudu ze vzdaleneho mesta, aby precetli logy a nedejboze sahli do konfigurace (ktere od odchodu Jardy nikdo nerozumi) a neco s tim udelali. Vase duvody na ne vetsinou delaji silny dojem jen do okamziku, nez zavesite telefon.
Smarja co resis? Nikomu neublizim, oni dostanou od sveho MTA hlasku o nedorucitelnbosti a muzou to zacit resit.Taky se přikláním k názoru to řešit jinak než zakázat konkretní IP...
s/bude/budu
Jak oni na mne, tak já ne ně. Nemám povinnost se od nich nechat obtěžovat.
Zcela běžně adresu zablokuji, aby se jim vracela chybová zpráva ICMP admin prohibited, a na whois tech-c/remark-abuse kontakt pošlu log se stížností.
Poslední dobou (především z Číny) se mi vrací zprávy o nedoručení (mailbox full/account doesn't exist). Když tam mají bordel, ať si ho užijí.
Ano, mluvím o útocích, ne o spamu. Ale problém to je stejný. Jediný způsob, jak zlepšit situaci, je donutit zdroj, aby ho to bolelo. Pak totiž pocítí potřebu záležitost řešit.
Nehledě na to, že rozzuřený soused má mnohem lepší pole působnosti, než já na druhém konci světa.
Zalezi na situaci (a pokud jde o utok, tak se s vami zcela ztotoznuji), ale naprikald u spamu
Když bude uživatel dostávat tolik spamu, že se v něm ztratí ham, tak uživatel takovou službu nebude chtít používat. Efektivně se jedná o DoS a srovnání s jakýmkoliv jiným neoprávněným/neúměrným využití služby je zcela na místě.
kdyz mate obrovskou sanci, ze takovy spam spravne vytridite, je blokovani vlastne priznanim vlastni neschopnosti
Ale já mám takovou šanci obvykle i u automatizovaných útoků. Mám vypracované systémy, které jsou schopny útok rozpoznat a dočasně jej neutralizovat. Přesto pravidelně procházím bezpečnostní hlášení, abych mohl zdroji vynadat.
Trvalou blokaci používám jako prevenci do budoucna (opětovné napadení stejným zdrojem je častý jev) a jako páku na druhý konec, aby byl motivován problém řešit. Pokud se zdroj ozve a zjedná nápravu, adresa je uvolněna.
Vůbec nejde o slabost, naopak se jedná o aktivní obranu. Když jsme u pořekadel, tak znáte to o útoku coby nejlepší obraně?
U one bolesti je proste treba vazit, zda ji nezpusobite spise nevinnym nez vinikovi.
Jistě. Ale v Internetu je nejmenší jednotkou IP adresa. Pokud si za ní někdo staví místní síť, je to skutečně jeho riziko. Na vyšších úrovní je zcela běžné blokování celých autonomních systémů.
Navic blokovani dava spammerum velmi efektivni moznost ladit metody a texty.
S tím jsem smířený. Já také ladím. Nevím, proč bych nemohl s nimi držet krok. Tím se totiž spamování spammerům prodraží, což je pádný důvod, proč přestat spamovat.
bud tolerantni na vstupu a presny na vystupu.
Netiketa má i další přikázání (svým jednáním neobtěžovat). Nemíním být hodný na ty zlé.
Také bych se rád zbavil blacklistů "natvrdo", ale nikde jsem nenašel nějaký rozumný článek jak donutit spamassassina přidávat jen body za účast v blacklistuNěco na tento způsob v user_prefs by nestačilo? Trošku jsem to rozepsal, ať tam je vidět víc možností....
header __TO_DOMAIN1 To =~ /(<)?[a-z,0-9,._-]+\@(domena1.org|domena1.info)(>)?(;)?[[:space:]]*$/i header __TO_DOMAIN2 To =~ /(<)?[a-z,0-9,._-]+\@domena2.net(>)?(;)?[[:space:]]*$/i meta __TO_VSICHNI (__TO_DOMAIN2 || __TO_DOMAIN2) ## hnusna@adresa.cz > *@domena2.net header __FROM_HNUSCZ From =~ /(<)?hnusna\@adresa.cz(>)?(;)?([[:space:]])*$/i meta FROM_HNUSCZ_TO_DOMAIN2 (__FROM_HNUZCZ && __TO_DOMAIN2) score FROM_HNUSCZ_TO_DOMAIN 100.0
smtpd_recipient_restrictions =
reject_rbl_client bl.spamcop.net
prostě ověřeni IP adresy, jestli není na blacklistu a podle toho jen přidělit body.
Ty blaclisty se pletou jen velmi zřídka, ale stane se to. A proto bych je chtěl jen jako body navíc.
score RCVD_IN_SBL 3 score RCVD_IN_XBL 3 score RCVD_IN_PBL 3skore si muzes zmenit jak chces. Tento priklad pouziva spamhaus.
FEATURE(`access.db', `hash -T <TMPF> /etc/mail/access')dnlna
FEATURE(`access.db', `hash -T <TMPF> /etc/mail/access', `relaytofulladdress')dnlViac tu. Slackware 12.1 to zapnute nemal. Potom je mozne pouzit v /etc/mail/access nasledovne:
domena.tld REJECT znamy1@domena.tld RELAY znamy2@domena.tld RELAYV logu je potom mozne vidiet ze email sa doruci iba pre adresata, ktory je uvedeny v access. LogLevel je v *.cf nastaveny na 16
O LogLevel=16----------------------------------
host sm-mta[20482]: NOQUEUE: connect from ukclean.gotadsl.co.uk [62.3.228.105] host sm-mta[20482]: AUTH: available mech=CRAM-MD5 DIGEST-MD5 LOGIN PLAIN OTP, allowed mech=EXTERNAL GSSAPI KERBEROS_V4 DIGEST-MD5 CRAM-MD5 host sm-mta[20482]: mAE79vta020482: Milter: no active filter host sm-mta[20482]: mAE79vta020482: --- 220 host.domena.tld ESMTP Sendmail 8.14.2/8.14.2; Fri, 14 Nov 2008 08:09:57 +0100 host sm-mta[20482]: mAE79vta020482: <-- HELO ukclean1 host sm-mta[20482]: mAE79vta020482: --- 250 host.domena.tld Hello ukclean.gotadsl.co.uk [62.3.228.105], pleased to meet you host sm-mta[20482]: mAE79vta020482: <-- MAIL FROM:<BradwinchMeyer@economist.com> host sm-mta[20482]: mAE79vta020482: --- 250 2.1.0 <BradwinchMeyer@economist.com>... Sender ok host sm-mta[20482]: mAE79vta020482: <-- RCPT TO:7<neznamy1@domane.tld> host sm-mta[20482]: mAE79vta020482: --- 550 5.2.1 <neznamy1@domane.tld>... Mailbox disabled for this recipient host sm-mta[20482]: mAE79vta020482: ruleset=check_rcpt, arg1=<neznamy1@domena.tld>, relay=ukclean.gotadsl.co.uk [62.3.228.105], reject=550 5.2.1 <neznamy@domena.tld>... Mailbox disabled for this recipient host sm-mta[20482]: mAE79vta020482: <-- RCPT TO:<neznamy2@domena.tld> host sm-mta[20482]: mAE79vta020482: --- 550 5.2.1 <neznamy2@domena.tld>... Mailbox disabled for this recipient host sm-mta[20482]: mAE79vta020482: ruleset=check_rcpt, arg1=<neznamy2@domena.tld>, relay=ukclean.gotadsl.co.uk [62.3.228.105], reject=550 5.2.1 <neznamy2@domena.tld>... Mailbox disabled for this recipient host sm-mta[20482]: mAE79vta020482: <-- RCPT TO:<znamy1@domena.tld> host sm-mta[20482]: mAE79vta020482: --- 250 2.1.5 <znamy1@domena.tld>... Recipient ok host sm-mta[20482]: mAE79vta020482: <-- DATA host sm-mta[20482]: mAE79vta020482: --- 354 Enter mail, end with "." on a line by itself host sm-mta[20482]: mAE79vta020482: from=<BradwinchMeyer@economist.com>>, size=717, class=0, nrcpts=1, msgid=<5301016521.20081111192666@economist.com>, proto=SMTP, daemon=MTA, relay=ukclean.gotadsl.co.uk [62.3.228.105] host sm-mta[20482]: mAE79vta020482: --- 553 5.0.0 neznamy1@domena.tld, neznamy2@domena.tld, znamy1@domena.tld... Unbalanced '>' (hold) host sm-mta[20482]: mAE79vta020482: --- 553 5.0.0 neznamy1@domena.tld, znamy1@domena.tld ... Unbalanced '>' (hold) host sm-mta[20482]: mAE79vta020482: --- 553 5.0.0 znamy1@domena.tld, neznamy1@domena.tld> ... Unbalanced '>' (hold) host sm-mta[20482]: mAE79vta020482: --- 553 5.0.0 neznamy1@domena.tld... Unbalanced '>' (hold) host sm-mta[20482]: mAE79vta020482: --- 553 5.0.0 neznamy1@domena.tld, neznamy1@domena.tld, znamy1@domena.tld... Unbalanced '>' (hold) host sm-mta[20482]: mAE79vta020482: --- 553 5.0.0 neznamy1@domena.tld, znamy1@domena.tld... Unbalanced '>' (hold) host sm-mta[20482]: mAE79vta020482: --- 553 5.0.0 znamy1@domena.tld, neznamy1@domena.tld... Unbalanced '>' (hold) host sm-mta[20482]: mAE79vta020482: --- 553 5.0.0 neznamy1@domena.tld... Unbalanced '>' (hold) host sm-mta[20482]: mAE79vta020482: --- 250 2.0.0 mAE79vta020482 Message accepted for delivery host sm-mta[20484]: mAE79vta020482: SMTP outgoing connect on host.domena.tld host sm-mta[20482]: mAE79vtb020482: <-- QUIT host sm-mta[20482]: mAE79vtb020482: --- 221 2.0.0 host.domena.tld closing connection host sm-mta[20484]: mAE79vta020482: to=<znamy1@domena.tld>, delay=00:00:01, xdelay=00:00:00, mailer=smtp, pri=120717, relay=[xxx.xxx.xxx.xxx] [xxx.xxx.xxx.xxx], dsn=2.0.0, stat=Sent (OK, mail data spooled) host sm-mta[20484]: mAE79vta020482: done; delay=00:00:01, ntries=1Snad to niekomu pomoze.
*** Qmail-Scanner Quarantine Envelope Details Begin *** X-Qmail-Scanner-Mail-From: "xxxx" via localhost X-Qmail-Scanner-Rcpt-To: "yyy" X-Qmail-Scanner: 2.05st (clamdscan: 0.94/8457. spamassassin: 3.2.5. perlscan: 2.05st. SPAM Found. Processed in 2.227756 secs) process 32553 Quarantine-Description: SPAM exceeds "quarantine" threshold - hits=33.7/5.0/5 SA_REPORT hits = 33.7/5.0 2.0 URIBL_BLACK Contains an URL listed in the URIBL blacklist [URIs: elite-russian-girls4you.biz] 1.9 URIBL_AB_SURBL Contains an URL listed in the AB SURBL blocklist [URIs: elite-russian-girls4you.biz] 1.5 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist [URIs: elite-russian-girls4you.biz] 1.5 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist [URIs: elite-russian-girls4you.biz] 1.5 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist [URIs: elite-russian-girls4you.biz] 0.5 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist [URIs: elite-russian-girls4you.biz] 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% [score: 1.0000] 4.3 RCVD_FORGED_WROTE2 RCVD_FORGED_WROTE2 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net [Blocked - see {http://www.spamcop.net/bl.shtml?89.121.125.42}] 0.0 HTML_MESSAGE BODY: HTML included in message 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level above 50% [cf: 100] 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level above 50% [cf: 100] 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% [cf: 100] 3.7 PYZOR_CHECK Listed in Pyzor (http://pyzor.sf.net/) 2.2 DCC_CHECK Listed in DCC (http://rhyolite.com/anti-spam/dcc/) 1.5 URIBL_SBL Contains an URL listed in the SBL blocklist [URIs: elite-russian-girls4you.biz] 0.0 DIGEST_MULTIPLE Message hits more than one network digest check 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS 3.7 XMAILER_MIMEOLE_OL_22B61 XMAILER_MIMEOLE_OL_22B61 *** Qmail-Scanner Quarantine Envelope Details End ***
Účinnost mého řešení přesahuje 90 % ... Ano, nějaký spam i tak sem tam proleze, ale pořád je zde ještě možnost nasazení zmiňovaného SpamAssassinu (na který je možno démona milter-greylist také připojit), který by účinnost dále dramaticky zvýšil.Klasická chyba měření účinnosti spam filtru. Účinnost spam filtru není dána jenom tím, jaký je podíl zastaveného spamu, ale také tím, jaký je podíl propuštěné regulérní pošty. Pokud budete účinnost měřit jenom tím prvním kritériem, je nejúčinnější vypnout mailserver.
smtps 465/tcp # SMTP over SSL (TLS)A nez svym nebohym clenum zablokujete odchozi tcp na 465ku, tak vezte, ze vetsinou se pri SSL/TLS pozaduje autentizace a pak jsou definovana efektivni pravidla, jak zamezit prilis intenzivnimu rozesilani mailu.
Oni totiz Vase postupy proste neuznavaji, nebot jsou samozrejme spatneMně je celkem jedno, jaké kdo používá postupy. Mně vadí jenom to, když někdo zahazuje regulérní e-maily. Ale to je asi marné vám vysvětlovat.
smtp.gmail.com
na portu 25 nepoužijete pro odeslání pošty mimo gmail.com
ani od ISP, který port 25 neblokuje. GMail s TLS totiž běží na portech 465 a 587.
smtp.gmail.com
odeslat.
Jiným řešením by bylo zkonfigurovat LDAP podporu v Sendmailu, který by si sám mohl existenci příjemce ověřit zasláním dotazu přímo na vnitřní LDAP server, ovšem to by znamenalo jisté bezpečnostní riziko...Proč myslíš, že je to bezpečnostní riziko?
Takový dementní mailserver nedělá lokální ukládání a nový pokus po půl hodině, jak bývalo dobrým zvykem.....Tak tady se musím tvrdě ohradit. Nazývat mail farmy "dementními mailservery" je nesprávné. RFC nic o nutnosti lokálního ukládání mailů neříká, takže nový pokus o odeslání může naprosto legitimně přijít z jiné IP. A to že vám to nabourá greylisting je vaše chyba - ne jeho.
Jednou jsem zaznamenal, že můj greylisting "clashnul" s kamarádovým "zpětným SMTP dotazem na existenci účtu odesilatele"To je klasický případ který už jsem tady zmiňoval - na chybě je váš kamarád, jehož MTA který obtěžuje svým dotazováním jiné mailservery. To je nejlepší cesta jak se dostat do blacklistu. Ideální řešení by mělo být pokud možno pasivní....
Takže vedle blacklistů IP adres budou vznikat blacklisty domén – jenomže nové a nové domény lze generovat snad ještě rychleji, než jak spammer získává nové odesílající počítače.To se ale stejně dělá už teď - za mail z příliš nové domény mi spamassassin dává body navíc a pokud je doména uvedená v tělě mailu/hlavičkách na spammerském blacklistu, tak už se mail zahodí.
.co.uk
?
Jedina okolnost, kterou nelze uspokojive vyresit je to, kdyz primarni server je mimo provoz (a dotycny zaznam neni v cache), pak zaloham nezbyde nic jineho nez to prijmout a pote vygenerovat eventuelni bounce - stale jsem presvedcen, ze chovat se v ramci prislusnych RFC je mensi zlo nez nefunkcni dorucovani (ze Telefonico?!).řekl bych, že čistší řešení je dočasně poštu odmítnout s poukazem na dočasné problémy. Na druhou stranu, právě SPF docela slušně snižuje pravděpodobnost, že mi přijde bounce na zprávu s mojí podvrženou adresou. Protože jsem si tam dal natvrdo doporučení odjinud odmítnout.