abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 06:00 | Zajímavý software

Byla vydána verze 0.56 open source platformy Home Assistant (GitHub) pro monitorování a řízení inteligentní domácnosti naprogramované v programovacím jazyce Python verze 3 a bežící také například na Raspberry Pi. Pro vyzkoušení je k dispozici demo [reddit].

Ladislav Hagara | Komentářů: 0
včera 16:55 | Nová verze

Byla vydána verze 1.0 klienta F-Droid určeného pro instalaci aplikací do Androidu ze softwarového repozitáře F-Droid (Wikipedie), alternativy k Google Play, nabízející pouze svobodný a otevřený software. Podrobnosti v přehledu změn [Hacker News].

Ladislav Hagara | Komentářů: 5
včera 00:55 | Nová verze

Po téměř 13 měsících vývoje od verze 0.11.0 byla vydána verze 0.12.0 hardwarově nenáročného desktopového prostředí LXQt (Lightweight Qt Desktop Environment, Wikipedie) vzniklého sloučením projektů Razor-qt a LXDE. Přehled novinek v příspěvku na blogu.

Ladislav Hagara | Komentářů: 9
21.10. 12:33 | Zajímavý software

Článek ne Medium představuje nejnovější stabilní verzi 2.0 svobodné decentralizované mikroblogovací platformy a sociální sítě podobné Twitteru Mastodon (Wikipedie). Detailní přehled novinek na GitHubu [Hacker News].

Ladislav Hagara | Komentářů: 0
21.10. 06:00 | Komunita

V Praze na půdě Elektrotechnické fakulty ČVUT dnes probíhá RT-Summit 2017 – setkání vývojářů linuxového jádra a uživatelů jeho real-time verze označované jako preempt-rt. Přednášky lze sledovat online na YouTube.

Ladislav Hagara | Komentářů: 0
20.10. 14:33 | Zajímavý projekt

Blender Animation Studio zveřejnilo první epizodu z připravovaného animovaného seriálu The Daily Dweebs o domácím mazlíčkovi jménem Dixey. Ke zhlédnutí také ve 3D s rozlišením 8K.

Ladislav Hagara | Komentářů: 0
20.10. 12:34 | Komunita

Aktualizovanou počítačovou hru Warhammer 40,000: Dawn of War III v ceně 39,99 eur běžící také na Linuxu lze o víkendu na Steamu hrát zdarma a případně ještě v pondělí koupit s 50% slevou. Do soboty 19:00 lze na Humble Bundle získat zdarma Steam klíč k počítačové hře Sid Meier's Civilization® III v ceně 4,99 eur běžící také ve Wine.

Ladislav Hagara | Komentářů: 0
20.10. 00:22 | Nasazení Linuxu

Společnost Samsung oznámila, že skrze dokovací stanici DeX a aplikaci Linux on Galaxy bude možno na Samsung Galaxy S8 a S8+ a Galaxy Note 8 provozovat Linux. Distribuce nebyly blíže upřesněny.

Phantom Alien | Komentářů: 19
19.10. 23:55 | Komunita

Společnost Purism na svém blogu oznámila, že její notebooky Librem jsou nově dodávány se zrušeným (neutralized and disabled) Intel Management Engine (ME). Aktualizací corebootu na již prodaných noteboocích lze Management Engine také zrušit. Více v podrobném článku.

Ladislav Hagara | Komentářů: 2
19.10. 21:44 | Nová verze

Organizace Apache Software Foundation (ASF) na svém blogu slaví páté výročí kancelářského balíku Apache OpenOffice jako jejího Top-Level projektu. Při této příležitosti byl vydán Apache OpenOffice 4.1.4 (AOO 4.1.4). Podrobnosti v poznámkách k vydání. Dlouhé čekání na novou verzi tak skončilo.

Ladislav Hagara | Komentářů: 8
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (10%)
 (0%)
 (0%)
 (1%)
 (76%)
 (13%)
Celkem 210 hlasů
 Komentářů: 8, poslední včera 23:02
    Rozcestník

    Stavíme poštovní server – 4 (SMTP, spam)

    6. 11. 2009 | Lukáš Jelínek | Sítě | 24323×

    Minule představená konfigurace programu Postfix sloužila jen k předávání zpráv na jiný server, bez jakýchkoli dalších aktivit. S tím se lze samozřejmě málokdy spokojit. Obvykle požadujeme výrazně více – server musí vykazovat určitou dávku vlastní „inteligence“.

    Obsah

    Plnohodnotný SMTP server

    link

    Přeposílající SMTP server se hodí pro případy, kdy potřebujeme jen přebírat zprávy (ať už od běžných poštovních klientů, nebo třeba od PHP skriptů) a předávat je skutečnému serveru, který už se postará o všechno ostatní. Pokud je ale potřeba zprovoznit skutečný server, který už vše doručuje sám a navíc se rozhoduje, od koho zprávy převezme, vyžaduje to už trochu více práce.

    V zásadě bude potřeba vyřešit tyto úkoly:

    • doručování cílovým serverům
    • omezení přístupu k serveru (základní ochrana proti spamu)
    • formální kontrola zpráv
    • blacklist/whitelist

    Všimněte si, že v seznamu chybí doručování místním uživatelům. To je zcela úmyslně, protože v tuto chvíli se bude jednat o server, který slouží pouze k odesílání, o místní doručování se nestará.

    Konfigurace doručování

    link

    Základem nového konfiguračního souboru bude samozřejmě ten z minulého dílu. Změní se jen to, co bude v tomto případě jinak. Především zmizí parametr relayhost a dále bude dobré změnit ještě pár dalších položek. Tady je výsledný konfigurační soubor main.cf:

    myhostname = postak.moje.domena
    myorigin = $mydomain
    
    inet_interfaces = all
    
    biff = no
    
    local_transport = error:no local mailboxes
    

    Odebrání relayhost způsobí, že bude server provádět dotazy na MX záznamy v DNS a podle nich se pokoušet doručovat zprávy na cílové servery. V souboru ale přibyla ještě jedna položka. Správně měla být už i v předchozím dílu (protože ani tam se nevyužívalo místní doručování), nicméně bylo cílem konfiguraci maximálně zjednodušit a Postfix funguje i bez ní. Parametr local_transport definuje místní transport (službu, která se použije k místnímu doručování). Výchozí službou je local, lze to ovšem změnit na error (tedy „chyba“) a službu local vypnout (viz dále). Za slovo error lze přidat dvojtečkou oddělenou zprávu, kterou klient dostane, pokud by se pokusil o lokální doručení.

    Vypnutí služby local je potřeba provést v souboru master.cf. Prostě se příslušný řádek služby local zakomentuje nebo smaže. Po každé změně konfiguračních souborů je potřeba vynutit nové načtení těchto souborů. Záleží na konkrétní distribuci, obvykle se to provádí přes /etc/init.d/postfix reload, případně obecně postfix reload. U některých změn (jmenovitě třeba nastavení síťových rozhraní, kde má Postfix naslouchat) to ale nestačí a celý Postfix se musí restartovat (např. /etc/init.d/postfix restart nebo postfix stop && postfix start).

    Restrikce na příjem pošty

    link

    Předchozí část byla zcela triviální. Nyní ovšem přichází něco trochu složitějšího, nicméně zcela nezbytného. Pokud bychom totiž server, který přijímá zprávy od kohokoliv (nebo aspoň od relativně široké množiny klientů), vystavili do Internetu, fungoval by jako tzv. open relay. Brzy by ho objevili spammeři a využili ho pro odesílání masivních dávek spamu. Zřejmě jen o něco později (nebo možná ještě dříve) by se dostal na černé listiny, které mnozí provozovatelé poštovních serverů využívají jako zdroj informací při boji proti spamu. Čili nic lákavého.

    Proto je potřeba říci, kdo bude smět odesílat přes tento server poštu, a podle toho pak také server nakonfigurovat. Obecně se používají tyto režimy:

    • restrikce podle adres/sítí
    • požadavek na autentizaci
    • omezení na doménu odesílatele

    Metod je obecně ještě víc, ale v tuto chvíli jsou důležité jen ty zde uvedené. Lze je různě kombinovat, a to jak ve smyslu logického součtu (tedy stačí vyhovět jednomu požadavku), tak součinu (všechny požadavky) nebo jinému vyhodnocení. Podívejme se nejdřív na problematiku adres počítačů a sítí, protože takto lze poměrně jednoduše vyřešit odesílání například z firemní sítě nebo ze serverů s pevnou adresou.

    Postfix má konfigurační parametr mynetworks. Používá se k definici „vlastních“ sítí, tedy těch, které mají větší práva, v tomto případě k odesílání pošty. S tímto parametrem úzce souvisí ještě parametr mynetworks_style, kterým se definuje výchozí hodnota parametru mynetworks. Tady je několik příkladů:

    mynetworks_style = class
    
    mynetworks_style = subnet
    
    mynetworks = 127.0.0.0/8, 192.168.1.0/24, [::1]/128
    
    mynetworks = $config_directory/mynetworks
    
    mynetworks = hash:/etc/postfix/mynetworks
    

    První dva příklady využívají výchozí hodnotu. Úplně nejobecnější je příklad první, který povoluje přístup z celé třídy IP. Vychází se samozřejmě ze síťových masek jednotlivých rozhraní, na nichž Postfix naslouchá. Čili pokud by měl například adresu 147.32.80.9/24, pak bude k serveru přístup z celé třídy C, konkrétně ze sítě 147.32.80.0. Druhý příklad je velmi podobný, ovšem s tím rozdílem, že lze specifikovat masku sítě jemněji než po celých třídách (pokud by při použití třídy byla maska např /28, stejně by se uplatnila maska třídy, tj. /24).

    Další tři příklady už používají přímo definice konkrétních adres. První z nich povoluje přístup ze všech lokálních adres a dále ze sítě 192.168.1.0 nacházející se ve vyhrazeném prostoru (typicky třeba firemní síť). Podobně lze uvést i přímo jedinou adresu bez masky. Při použití IPv6 se musí používat hranaté závorky, jak je vidět ze zde uvedené lokální IPv6 adresy (to proto, že dvojtečky mají jinak jiný význam, používají se pro nastavení datového zdroje – viz hash).

    Zbývající dva příklady ukazují využití vnějších zdrojů informací (mimo konfigurační soubor). První využívá obyčejný textový soubor, kde jsou povolené adresy uvedeny ve stejné formátu, jako by se uváděly přímo v konfiguraci. Druhý příklad pracuje s hešovou tabulkou – jednotlivé adresy se nejprve vloží do souboru /etc/postfix/mynetworks v textové formě (vždy adresa a libovolný řetězec oddělené mezerou) a pak se na soubor zavolá postmap (tj. zde postmap /etc/postfix/mynetworks), který vygeneruje vlastní tabulku. Soubor s vygenerovanou tabulkou bude mít příponu .db, ta se ale v konfiguraci neuvádí.

    Dál už ani na krok!

    link

    Zadefinovat si jen příslušné parametry nestačí. Je potřeba ještě říci Postfixu, aby podle nich řídil přístup. Začneme tím, že bude odesílání omezeno pouze podle příslušnosti odesílajícího počítače k definovaným „vlastním“ sítím. Tady je to ovšem bez práce, protože výchozí konfigurace Postfixu je taková, že se automaticky zakazuje odesílání pošty z adres mimo mynetworks. Výchozí nastavení je ekvivalentní tomuto:

    smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination
    

    Restrikční pravidla vždy fungují stylem, že pokud některé z nich zafunguje (při vyhodnocování v pořadí, jak jsou napsána), další se již nevyhodnocují. Zde se tedy nejdřív povolí přístup pro adresu z vlastních sítí a pak se případně odmítne přístup všem ostatním (ovšem viz dále). K odmítnutí v tomto případě dojde v okamžiku, kdy protistrana poskytne adresu příjemce (SMTP příkaz RCPT TO). Povolen je přístup z vlastních sítí a odmítne se doručení do neautorizovaných cílů. To je z hlediska ochrany proti spamu v zásadě dostatečné, nicméně je to zbytečně pozdě a spammera lze „zaříznout“ hned zčerstva, navíc to lze udělat ještě důkladněji. Tady je nastavení, které lze použít:

    smtpd_client_restrictions = permit_mynetworks, reject
    smtpd_delay_reject = no
    

    První parametr je podobný tomu předchozímu, tedy definuje přístup klientů, ovšem v tomto případě již pro samotné připojení. Protože ale ve výchozím stavu Postfix kontrolu stejně odloží až na okamžik po příkazu RCPT TO, druhým parametrem se tento odklad vypne. Neoprávněný klient tedy dostane odmítací zprávu okamžitě po připojení. Je otázka, nakolik je to v pořádku. Na jednu stranu se tím šetří výkon, který by spammeři požírali – současně s tím však některé klientské programy nemusí počítat, byť jde o chování v souladu se specifikací protokolu. Proto je dobré zvážit, nakolik je přidání druhého řádku potřebné (obvykle spíše ne).

    Zde se sluší připomenout, jaký je rozdíl mezi reject_unauth_destination a pouhým reject. reject odmítá zcela bezpodmínečně, kdežto reject_unauth_destination povolí doručení do lokálních schránek (zde bezpředmětné – lokální doručování je vypnuto) a také předávání pro specifikované domény, pokud tak má server činit.

    Dále se můžeme rozhodnout, že půjdou odesílat jen zprávy s odesílatelem v definovaných doménách. Sice by šlo pak vynechat kontrolu IP adres klientů, ale to už by poměrně slušně otevíralo dvířka spammerům. Takže postup bude opačný – kontrola sítí se ponechá v platnosti a ještě se přidá kontrola domén:

    smtpd_sender_restrictions =
      check_sender_access hash:/etc/postfix/access,
      reject
    

    Příklad ukazuje hned několik věcí současně. Jednak je to využití víceřádkového nastavování parametru (čistě pro přehlednost; další řádky se vždy odsazují), dále je to využití blacklistu/whitelistu v hešové tabulce a nakonec použití parametru pro omezení odesílatele. Pokud není nastaveno smtpd_delay_reject = no, kontrola se provede opět až při příkazu RCPT TO. Povolen bude přístup pouze pro adresy odesílatele odpovídající whitelistu – viz dále.

    Blacklist/whitelist

    link

    V Postfixu lze s výhodou využít kombinovaný blacklist/whitelist dostupný prostřednictvím jednoho datového zdroje. Ve výše uvedeném případě je to hešová tabulka, ale může to být klidně třeba databáze nebo nějaký externí server. Tabulka slouží pro dotazy – a to jak na kompletní adresy, tak na uživatelská jména (jméno@) a na domény, což je to, co je využito výše.

    V tabulce (datovém zdroji) jsou obsaženy dvojice klíč-hodnota, což znamená, že se Postfix dotáže klíčem a zdroj vrátí hodnotu (nebo nic, pokud není klíč nalezen). Konkrétně v black/whitelistu je to tak, že je vždy e-mailová adresa, uživatel nebo doména jako klíč a jako hodnota je uvedeno, jaká akce se má udělat.

    Je-li uvedeno OK, znamená to v tomto případě, že je klíč na whitelistu (tedy zde konkrétně, že se smí z dané domény odesílat; podobně lze vkládat do seznamu i jednotlivé adresy). Je-li uvedeno REJECT, nemá to pro výše uvedený příklad žádný význam, nicméně to vkládá adresu/doménu/uživatele na blacklist, což lze využít například takto:

    smtpd_recipient_restrictions =
      check_recipient_access hash:/etc/postfix/access,
      permit
    

    Tato definice zakáže posílání zpráv příjemcům (a do domén) na blacklistu. V tomto případě to nemá příliš uplatnění, ale velmi podobně by se blacklist uplatnil pro příchozí zprávy, pokud by je server přijímal z vnějšího světa. Ještě pro úplnost – hodnot vracených datovým zdrojem může být víc, podrobnosti najdete v manuálové stránce access(5).

    Formální kontroly

    link

    V rámci nastavování restrikcí pro přístup k serveru lze také zapnout různé formální kontroly zpráv. K čemu je to dobré? Třeba pro boj s odchozím spamem. Některý z uživatelů může mít na počítači nějakou „havěť“, která začne odesílat spam. Protože si tvůrci často nelámou hlavu s dodržováním nějakých specifikací, lze důslednou kontrolou tento spam omezit.

    Následující příklad bude ukazovat společně celý úsek věnovaný restrikcím (kromě definice mynetworks). Navíc se v něm objeví ještě pár dalších parametrů vysvětlených níže.

    smtpd_client_restrictions =
       permit_mynetworks,
       reject
    
    smtpd_sender_restrictions =
       reject_non_fqdn_sender,
       reject_unknown_sender_domain,
       check_sender_access hash:/etc/postfix/access,
       reject
    
    smtpd_recipient_restrictions =
       reject_non_fqdn_recipient,
       reject_unknown_recipient_domain,
       check_recipient_access hash:/etc/postfix/access,
       permit
    
    smtpd_error_sleep_time = 30
    smtpd_soft_error_limit = 10
    smtpd_hard_error_limit = 20
    
    smtpd_helo_required = yes
    

    V uvedených pravidlech toho není až tolik nového. Důležité jsou však kontroly reject_non_fqdn_senderreject_non_fqdn_recipient – tyto kontroly způsobí odmítnutí adresy odesílatele, resp. příjemce, pokud neobsahuje plně kvalifikované doménové jméno (podle RFC 2822). Další kontroly jdou ještě dál. reject_unknown_sender_domain, resp. reject_unknown_recipient_domain odmítnou neexistující domény (podle kontroly v DNS), a to dokonce i v případě, že jsou uvedeny ve whitelistu. Oba druhy kontrol zabraňují odesílání pošty z nesmyslných zpátečních adres a na nesmyslné cílové adresy (kontroluje se zde samozřejmě jen doména, ne celá adresa). Obě kontroly zde sdílí jediný datový zdroj, nicméně mohou mít samozřejmě každá svůj vlastní.

    Ochranný význam mají i tři parametry ke konci příkladu. První hodnota říká, kolik sekund má Postfix čekat, pokud klient dosáhne „měkkého“ limitu počtu chyb (chybou je cokoliv, co vyvolá kód 4xx nebo 5xx), aniž by byla předána zpráva. Tento měkký limit se nastavuje druhým parametrem. Třetí parametr je pak tvrdý limit počtu chyb – po jeho dosažení je klient odpojen.

    Úplně poslední parametr zakazuje vynechání příkazu HELO nebo EHLO. Na tento příkaz lze navázat další kontroly, nicméně to není příliš dobrý nápad, protože podpora správného použití je u mnohých klientů dost svérázná, takže by to zadělalo na slušné problémy. Ovšem protože tento úvodní identifikační příkaz musí podle specifikace poslat každý klient, je dobré z toho udělat povinnost, což eliminuje spamující software, který pravidla nedodržuje.

    Kde jsou poštovní schránky

    link

    Kde jsou? Zatím nikde. Zato příště už budou, a to hned ve dvou verzích – jako systémové (schránky místních uživatelů) a jako virtuální (pro uživatele, kteří nemají účet v systému). Na scénu se dostane už i druhý z programů, Dovecot, který zatím odpočíval.

           

    Hodnocení: 78 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    6.11.2009 01:32 Ivanhoej | skóre: 26 | blog: ss2_Debian | Bratislava
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 4 (SMTP, spam)
    "plně kvalifikované doménové jméno" sa spomina aj v RFC3461 v SMTP nema to byt toto?
    *** Jabber (XMPP): fogo@jabber.cz ***
    Luk avatar 6.11.2009 06:52 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 4 (SMTP, spam)
    RFC3461 řeší notifikace o stavu doručení. Formátem e-mailových zpráv se zabývá RFC2822 (a nově také RFC5322, zatím ve fázi draftu). Nicméně v tomto případě jsem spíše měl odkázat na RFC2821 (resp. draft RFC5321), protože jde o obálkové adresy, nikoli o adresy uvnitř zprávy. Konkrétně jde o toto:
    A domain name that is not in FQDN form is no more than a local alias. Local aliases MUST NOT appear in any SMTP transaction.
    V jiných variacích se to objevuje ještě na dalších místech specifikace.
    LinuxMarket - linuxový e-shop | LinuxEXPRES - linuxový magazín | OpenOffice.cz - portál uživatelů OpenOffice/LibreOffice
    6.11.2009 08:25 stderr
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 4 (SMTP, spam)
    "Zato příště už budou" - abclinuxu umí předpovídat budoucnost. V závěru je odkaz na článek, který je naplánován (?) na 13.11. - a je pro obyčejného uživatele už dnes čitelný :)
    6.11.2009 08:33 Zdenek 'Mst. Spider' Sedlak | skóre: 37 | blog: xMstSpider
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 4 (SMTP, spam)
    Jo, tohle je hodne dobry :-) Tak nejak si rikam, odkud se to datum bere, zil jsme blahove v tom, ze to znamena kdy BYL clanek vydany, ale do toho chybi jeste tyden :D
    6.11.2009 09:47 Robert Krátký | skóre: 94 | blog: Robertův bloček
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 4 (SMTP, spam)
    Oops... link odstraněn, nic jste neviděli.
    6.11.2009 09:41 pepazdepa
    Rozbalit Rozbalit vše spravny nadpis clanku?
    nejak mi nedochazi ten nadpis clanku... ano je to o zabezpecni pouzivat nas mail server jako relay apod, ale kde je ten boj proti spamu?

    jinak existuji nastaveni kde jde blokovat hodne rovnou postfixem bez zatezovani systemu spamassissinem apod (body_checks, header_checks...).
    Luk avatar 6.11.2009 11:08 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
    Rozbalit Rozbalit vše Re: spravny nadpis clanku?
    nejak mi nedochazi ten nadpis clanku... ano je to o zabezpecni pouzivat nas mail server jako relay apod, ale kde je ten boj proti spamu?
    Ten nadpis je redakční (tj. nepsal jsem ho já - moje chyba, že jsem žádný nedodal;-)), nicméně logiku má - jsou tam i určitá (byť velmi jednoduchá) opatření proti spamu.
    jinak existuji nastaveni kde jde blokovat hodne rovnou postfixem bez zatezovani systemu spamassissinem apod (body_checks, header_checks...).
    Ano, mám v plánu se tím zabývat v pozdějších dílech.
    LinuxMarket - linuxový e-shop | LinuxEXPRES - linuxový magazín | OpenOffice.cz - portál uživatelů OpenOffice/LibreOffice
    6.11.2009 11:48 petr.motejlek | skóre: 4 | Sloveč
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 4 (SMTP, spam)
    Chtěl bych jen upozornit začínající čtenáře, aby před nasazením opatření typu reject_unknown_sender_domain (reject_invalid_hostname) vyzkoušeli, že všichni, kdo jim budou e-maily posílat, mají pro svůj e-mailový server vyhrazeno doménové jméno atd.

    Setkal jsem se již s mnohými (i velkými) firmami, kteří to tak neměli a pak byl problém, protože e-maily od nich nebyly přijaté, a upřímně, kdo v business sektoru vám bude volat, že mu neberete e-mail, to se na vás vy*ere a půjde jinam ;).
    6.11.2009 13:08 Roman
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 4 (SMTP, spam)
    Presne, tyto pravidla se v praxi bohuzel pouzit nedaji, nebot hrozi pruser.
    Luk avatar 6.11.2009 14:14 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 4 (SMTP, spam)
    To se ovšem IMHO netýká reject_unknown_sender_domain, protože jestliže někdo posílá zprávu a očekává na ni nějakou odpověď, měl by ji poslat z domény, která existuje. Jinak by mu stejně nemohla přijít odpověď (nestandardní konfigurace klientů, kdy se adresa pro odpověď nastavuje jiná než adresa odesílatele, nepočítám - když někdo nastavuje toto, nastaví obvykle správně i název domény pro adresu odesílatele). Čili vůbec bych toto nesměšoval s věcmi jako je reject_invalid_hostname, reject_unknown_client_hostname, reject_unknown_reverse_client_hostname apod.
    LinuxMarket - linuxový e-shop | LinuxEXPRES - linuxový magazín | OpenOffice.cz - portál uživatelů OpenOffice/LibreOffice
    7.11.2009 00:53 petr.motejlek | skóre: 4 | Sloveč
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 4 (SMTP, spam)
    Ano, pravda, tu direktivu jsem na mysli neměl ;). Kopíroval jsem to ze zálohy jednoho konfiguráku a nějak to dopadlo blbě :D.
    AraxoN avatar 6.11.2009 14:18 AraxoN | skóre: 45 | blog: slon_v_porcelane | Košice
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 4 (SMTP, spam)
    Bol som v tom, že RFC vyžaduje správne doménové meno a reverzný záznam. Ak to tak je, tak nevidím problém v odpílení zle nastavených serverov - nech si to nastavia správne, alebo nech s tým nelezú na Internet. Ak je totiž zle nastavená tak elementárna vec, tak je dosť pravdepodobné, že sú zle nastavené aj iné veci, a že server pracuje v režime open-relay.
    A fine is a tax for doing wrong. A tax is a fine for doing well.
    7.11.2009 00:51 petr.motejlek | skóre: 4 | Sloveč
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 4 (SMTP, spam)
    RFC to sice vyžadovat může, ale pokud má 70 % lidí Microsoft Exchange nebo cokoliv, co se ne vždy chová přesně tak, jak říká RFC (nebo to jsou prostě šmejdi a neumí nastavit Postfix, Sendmail, Qmail, ...), tak mi stejně zákazník řekne, že bude radši, když mu do schránky přijde denně o 3 spamové zprávy víc, hlavně, že se mu jeho zákazník e-mailem nějak ozve ;).
    AraxoN avatar 7.11.2009 10:35 AraxoN | skóre: 45 | blog: slon_v_porcelane | Košice
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 4 (SMTP, spam)
    smtpd_sender_restrictions = reject_invalid_hostname, reject_unknown_sender_domain, reject_non_fqdn_sender, ...
    - takto to používame odjakživa (cca. od roku 2003) a nikdy s tým nebol problém. Pritom nehostujeme len naše veci, ale aj mailboxy pre cca stovku zákazníkov a ich domén. Budem sa opakovať, ale ak si niekto nevie nastaviť mailový server (a vyriešiť s providerom správne doménové meno), tak nech si ten mailový server nedáva na internet.
    A fine is a tax for doing wrong. A tax is a fine for doing well.
    7.11.2009 12:06 petr.motejlek | skóre: 4 | Sloveč
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 4 (SMTP, spam)
    Důležité je, jaké je složení těch Vašich zákazníků. Jestli to všechno je IT-related, tak se není o čem bavit. Já mám tuto zkušenost z běžných obchodních společností, kde to takhle vážně funguje. Nechci zde žádnou firmu jmenovat, ale zrovna nedávno se u jednoho zákazníka stalo (po zavedení mimo jiné i pravidel, která uvádíte), že mu od mimo jiné 3 poměrně velkých firem podnikajících i v ČR, nedorazily e-maily, protože ty firmy prostě mají e-mailové servery, které mají sice veřejné IP adresy, ale už neexistuje pro ty IP adresy Ačkový DNS záznam :(.

    Tohle vlákno bychom měli ukončit ;) Důležité sdělení je, že každý, kdo chce nějak striktněji konfigurovat někomu MTA, tak si musí dát pozor na složení odesílatelů a příjemců, kteří ten server budou využívat, aby se nedostal do problémů.
    AraxoN avatar 7.11.2009 13:28 AraxoN | skóre: 45 | blog: slon_v_porcelane | Košice
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 4 (SMTP, spam)
    IT related ich je veľmi málo. Sú tam firmy všetky možné - z oblasti ubytovania, stravovania, výroby, vzdelávania, obchodu, konzultácií, účtovníctva, právnych služieb, auto-moto, reklamy, turizmu, aj iné. Ale OK, svoje stanoviská sme si v tomto vlákne už povedali, takže to ďalej nemusíme riešiť. :)
    A fine is a tax for doing wrong. A tax is a fine for doing well.
    7.11.2009 12:07 Filip Jirsák | skóre: 67 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 4 (SMTP, spam)
    Nevyžaduje to úplně stoprocentně – podle RFC to tak má být, ale v odůvodněných případech jsou možné i výjimky.
    6.11.2009 22:35 Kvakor
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 4 (SMTP, spam)
    Presne, tyto pravidla se v praxi bohuzel pouzit nedaji, nebot hrozi pruser.
    To není úplně přesné, přísná pravidla se použít mohou, pokud je legitimní klienti mají šanci obejít - buďto whitelistem, nebo tím, že náhradní MX servery nejsou tak přísné. Pokud je v důsledku chybné konfigurace odesílající server nepřipuštěn k primárnímu mailserveru, může poslat mail skrz sekundární (např. mailserver poskytovatele připojení). Protože postupné vyzkoušení všech mailserverů z MX záznamu je povinnou částí SMTP, tak s tím legitimní klienti nemají problém, ale odřízne to minimálně 90% spamu.
    MMMMMMMMM avatar 7.11.2009 01:35 MMMMMMMMM | skóre: 42 | blog: unstable | Valašsko :-)
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 4 (SMTP, spam)
    záložní mx servery jsou zlo ;-)
    Luk avatar 7.11.2009 10:48 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 4 (SMTP, spam)
    On je hlavně problém, že mnozí spammeři vcelku oprávněně očekávají, že budou záložní servery slaběji chráněny než servery primární. Proto je zkouší jako první. Takže pokud se má využívat jeden nebo více záložních serverů, je potřeba je nastavit se stejnou úrovní ochrany jako ty primární (a nejlépe ještě synchronizovat mezi nimi antispamové databáze).
    LinuxMarket - linuxový e-shop | LinuxEXPRES - linuxový magazín | OpenOffice.cz - portál uživatelů OpenOffice/LibreOffice
    6.11.2009 14:50 R
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 4 (SMTP, spam)
    X rokov mame na firemnom serveri nastavene "smtpd_server_rescrictions = reject_non_fqdn_server, reject_unknown_sender_domain". Nehovori to nic o serveri ale o adrese odosielatela, ktora musi mat platnu domenu.
    9.11.2009 15:26 oron | skóre: 27
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 4 (SMTP, spam)
    "X rokov mame na firemnom serveri nastavene "smtpd_server_rescrictions = reject_non_fqdn_server,"

    nema tam byt nahodou reject_non_fqdn_sender ?
    (reject_non_fqdn_server nemozem najst nikde)
    18.2.2016 08:30 Mintaka_
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 4 (SMTP, spam)
    Je to chybně, včetně názvu toho pravidla, které má být smtpd_sender_restrictions
    9.11.2009 21:31 dalibor
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 4 (SMTP, spam)

    Kombinace pravidel

    Dobry den, v clanku se pise, ze lze ruzne kombinovat restrikce. Chtel bych se zeptat jak lze zkombinovat nasledujici dve situace, ktere nastavaji zaroven. Samostatne bych celkem vedel jak restrikce nastavit, ale jak je nastavit tak, aby zafungovaly dohromady to moc netusim.

    1) smtp server pro odesilani mailu do internetu

    mail (domena.cz) (klient) => serv1 (192.168.0.21) => postfix (192.168.0.1) => internet

    • restrikce na odesilatele jen (domena.cz)
    • restrikce na vybrane odesilatele napr. info@domena.cz, nesmi odesilat email
    • restrikce na IP adresu odesilatele 192.168.0.21

    2) stahovani pop3 schranky a dorucovani na serv1

    pop3.domena.cz (internet) => fetchmail (192.168.0.1) => postfix (192.168.0.1) => serv1 (192.168.0.21)

    • restrikce na prijemce jen pro (domena.cz)
    • restrikce na odesilatele domena.cz (v internetu by nikdo takovy email mit nemel, protoze je to moje domena)
    • pripadne restrikce na jednotliveho odesilatele info@domena.cz
    • restrikce na IP adresu (fetchmail = localhost).

    Za odpoved dekuji.

    Luk avatar 10.11.2009 07:02 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 4 (SMTP, spam)
    Jestli jsem to správně pochopil, tak jde v zásadě o to, aby ve druhé sadě byla navíc restrikce na příjemce (restrikce na odesílatele je stejná a realizovala by se blacklistem). Takže mě jako nejschůdnější napadá zhruba něco takového:
    mynetworks = 127.0.0.0/8
    
    smtpd_client_restrictions =
        permit_mynetworks,
        check_client_access hash:/etc/postfix/client-access,
        reject
    
    smtpd_sender_restrictions =
        check_sender_access hash:/etc/postfix/sender-access,
        reject
    
    smtpd_recipient_restrictions =
        check_client_access hash:/etc/postfix/client-access,
        check_recipient_access hash:/etc/postfix/recipient-access,
        reject
    
    Přičemž v client-access by byla adresa 192.168.0.21, v sender-access doména domena.cz (případně jednotlivé adresy) a v recipient-access opět doména domena.cz. Klíčová práce by se odehrávala v smtpd_recipient_restrictions, kde by to nejdřív povolilo klienta 192.168.0.21 pro odesílání odkudkoliv a potom příjemce v doméně domena.cz, ostatní by bylo zakázáno. Podle mě by to mělo fungovat, tedy aspoň pokud jsem správně pochopil, co má být cílem.
    LinuxMarket - linuxový e-shop | LinuxEXPRES - linuxový magazín | OpenOffice.cz - portál uživatelů OpenOffice/LibreOffice
    10.11.2009 23:35 dalibor
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 4 (SMTP, spam)
    Dekuji za odpoved, pomohla. Sice doslovne jak to popisujete to nezafungovalo, ale "myslenku" jsem pochytil a aplikoval ke sve spokojenosti. Jeste jednou diky ;-).
    23.2.2010 08:36 okoun
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 4 (SMTP, spam)
    nějak mi to stále nefunguje dle doho nastavení, mám nastaveno:

    # See /usr/share/postfix/main.cf.dist for a commented, more complete version

    # Debian specific: Specifying a file name will cause the first # line of that file to be used as the name. The Debian default # is /etc/mailname.

    #smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)

    # appending .domain is the MUA's job. # append_dot_mydomain = no

    # Uncomment the next line to generate "delayed mail" warnings # delay_warning_time = 4h

    # readme_directory = no

    # TLS parameters # smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem # smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key # smtpd_use_tls=yes # smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache # smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

    # See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for # information on enabling SSL in the smtp client.

    myhostname = dream.matejov.eu myorigin = $mydomain # alias_maps = hash:/etc/aliases # alias_database = hash:/etc/aliases mydestination = srsniste-server, localhost.localdomain, , localhost

    mynetworks = 10.55.0.0/22, 127.0.0.0/8 mynetwork = www.matejov.org # mailbox_size_limit = 10000 # recipient_delimiter = + inet_interfaces = all

    biff = no

    local_transport = error:no local mailboxes

    smtpd_client_restrictions = permit_mynetworks, reject smtpd_delay_reject = no

    a píše to chybu:

    Feb 22 22:29:04 dream-matejov postfix/smtp[28525]: connect to mx.volny.cz[212.20.96.186]:25: Connection timed out Feb 22 22:29:04 dream-matejov postfix/smtp[28533]: connect to mx.volny.cz[212.20.96.186]:25: Connection timed out Feb 22 22:29:04 dream-matejov postfix/smtp[28528]: connect to mail.matejov.eu[93.185.104.5]:25: Connection timed out Feb 22 22:29:04 dream-matejov postfix/smtp[28542]: connect to mx.volny.cz[212.20.96.180]:25: Connection timed out Feb 22 22:29:04 dream-matejov postfix/smtp[28545]: connect to mail.matejov.eu[93.185.104.5]:25: Connection timed out Feb 22 22:29:34 dream-matejov postfix/smtp[28530]: connect to mx.volny.cz[212.20.96.180]:25: Connection timed out Feb 22 22:29:34 dream-matejov postfix/smtp[28535]: connect to mx.volny.cz[212.20.96.180]:25: Connection timed out

    nic se neodešle :(

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.