Antispam: Co zvládne samotný Postfix

21. 12. 2009 | Lukáš Jelínek | Sítě | 23100×

Co zvládne samotný Postfix

Přestože je Postfix poměrně úzce funkčně zaměřený program, obsahuje docela širokou škálu prostředků použitelných pro boj proti spamu. Některé z nich už se objevovaly v dřívějších článcích, na některé dojde řada až teď.

Již v dřívějších článcích můžete najít například použití lokálních blacklistů a whitelistů, základní formální kontrolu, požadavek na příkaz EHLO/HELO, vypnutí příkazu VRFY nebo reakci na chyby v protokolu SMTP. To jsou všechno zajímavé a důležité věci, nicméně jejich praktický přínos není až tak výrazný. Proto lze přidat další metody.

Limity pro klienty

Někteří spammeři mají při svých pokusech doslova kulometnou kadenci a jsou schopni server zahlcovat v mnoha relacích najednou, přestože se jim pak třeba povede doručit jen minimum zpráv. Tomu se lze bránit:

smtpd_client_connection_rate_limit = 20
smtpd_client_message_rate_limit = 30
smtpd_client_event_limit_exceptions = hash:/etc/postfix/nolimit-clients.map

První parametr říká, kolik pokusů o připojení smí klient maximálně provést za časovou jednotku. Ve výchozím nastavení tento počet není omezen. Časová jednotka je standardně nastavena na 1 minutu, lze ji však změnit parametrem anvil_rate_time_unit. Druhý parametr má podobný význam, omezuje ale počet předaných zpráv. A konečně třetí parametr umožňuje nastavit (v tomto případě pomocí tabulky, výchozí hodnota odpovídá parametru mynetworks), na které klienty se limity nebudou vztahovat. Tak lze zabránit aplikaci limitů například na stanice ve vlastní síti, na vlastní webové či jiné servery anebo na prověřené servery, z nichž přívaly spamu nehrozí.

Limity je třeba nastavovat tak, aby legitimní pošta nebyla omezována. Optimální je analyzovat, jaké frekvence připojení, resp. předávání zpráv od stejného klienta se v normálním provozu vyskytují, limity potom podle toho nastavit. Pokud se objevují problémy s tím, že jsou připojení nebo zprávy odmítány, je třeba limity zvýšit nebo změnit časovou jednotku. Existují ještě další limity:

smtpd_client_recipient_rate_limit = 300
smtpd_recipient_limit = 100
smtpd_recipient_overshoot_limit = 10

První z limitů se týká počtu příjemců za časovou jednotku, druhý je maximální počet příjemců na zprávu. Poslední parametr pak říká, jak velké překročení limitu příjemců na zprávu ještě nebude považováno za chybu, která je po dosažení určitého počtu penalizována pozastavením relace („měkká“ chyba), resp. odpojením klienta („tvrdá“ chyba).

Vzdálené blacklisty

Postfix může využívat některé vzdálené blacklisty a na základě jejich informací odmítat zprávy. Je to výkonově nenáročné, ale současně také nebezpečné, protože se běžné servery mohou za určitých okolností (většinou zcela po právu, ale to uživatele obvykle naprosto nezajímá) na některé blacklisty poměrně snadno dostat.

Proto jsou následující příklady vhodné tam, kde má ochrana před spamem (a nízká zátěž serveru) výrazně vyšší prioritu než případné nedoručování legitimních zpráv. Pravidla pro restrikce klientů lze například upravit tímto stylem:

smtpd_client_restrictions =
  permit_mynetworks,
  check_sender_access hash:/etc/postfix/access,
  reject_rhsbl_client blackhole.securitysage.com,
  reject_rbl_client bl.spamcop.net,
  reject_rbl_client dnsbl.njabl.org,
  permit

Nové testy přibyly pod ověřením v místním blacklistu/whitelistu (ten má samozřejmě přednost). Pravidlo reject_rhsbl_client způsobí odmítnutí klienta, který je uveden v seznamu služby blackhole.securitysage.com. Test se v tomto případě provádí u služby, která vyžaduje původní (nepřevrácené) pořadí bajtů u IP adresy. Druhé dvě kontroly se dotazují služeb vyžadujících obrácené pořadí bajtů (podobně jako u reverzních DNS dotazů).

Připojí-li se klient, Postfix se postupně dotazuje jednotlivých služeb na jeho IP adresu. Vrátí-li některá ze služeb, že má adresu na seznamu, další kontroly se již neprovádějí a klient je odmítnut. Lze přidat libovolný počet služeb (bezplatných i placených), ovšem s tím, že se tak prodlužuje doba, kterou trvá ověřování klientů a současně se zvyšuje pravděpodobnost falešného uvedení v seznamu. Je proto dobré zvolit si raději méně služeb a jen takové, které odpovídají požadavkům na prováděné kontroly.

Jednou z potenciálně nebezpečných služeb je například rfc-ignorant.org. Ta totiž přidává na svůj seznam servery, které ignorují požadavky RFC pro poštovní komunikaci (například jim nefunguje povinná schránka postmaster). Sice je to dobrý nástroj k nucení správců serverů, aby měli vše v pořádku, ale současně se používáním této služby odříznou mnohé legitimní servery, jejichž správci něco zanedbali. Například server oblíbeného freemailu Seznam.cz byl u této služby evidován necelých 6 let, odstraněn byl teprve přibližně před rokem.

Podobně jako restrikce na klienty lze provádět i restrikce na odesílatele. Slouží k tomu kontrola reject_rhsbl_sender nebo reject_rbl_sender, kterou lze použít v restrikčním parametru smtpd_sender_restrictions. Existuje i možnost takto kontrolovat příjemce, to ale v tomto případě postrádá smysl (může to mít smysl v případech, kdy je třeba chránit server při odesílání ven, například pokud hrozí napadení stanic malwarem rozesílajícím spam).

Pokud není nastaveno smtpd_delay_reject = no, lze všechny restrikce přesunout do parametru smtpd_recipient_restrictions, aniž by to mělo vliv na sémantiku (samozřejmě při dodržení logického pořadí kontrol). Odmítnutí klienta totiž stejně proběhne až ve fázi po příkazu RCPT TO. Rozepsání restrikcí do jednotlivých částí je však přehlednější a hlavně ve složitějších případech je lépe vidět, jak se přesně server chová. Podobný smysl má také uvádění permit na konci řetězce kontrol – implicitně je totiž přístup povolen, uvedení permit však na první pohled signalizuje, že tomu tak je.

Kontrola DNS záznamů

Zajímavé kontroly jsou ověřování DNS záznamů. Poštovní server by měl mít vždy správný MX záznam (pro každou doménu, kterou obsluhuje), A záznam (pro jmennou adresu uvedenou v MX záznamu) a odpovídající PTR záznam (reverzní). Případně MX záznam mít nemusí, ale zbytek platí dál. Například pro doménu abclinuxu.cz existuje (mimo jiné) MX záznam směřující na adresu aspmx.l.google.com. Musí tedy existovat A záznam pro tuto adresu (existuje a aktuálně vede na IP adresu 209.85.220.30), dále PTR záznam pro uvedenou IP adresu (existuje a vede na adresu mail-fx0-f30.google.com, pro niž existuje A záznam vedoucí rovněž na 209.85.220.30).

Co z uvedeného vyplývá? Že to není až tak úplně košer, protože se v MX záznamu objevuje adresa dostupná přes záznam CNAME (nicméně nejde vysloveně o chybu; poštovní servery Googlu mají i jiný, větší problém – viz dále), ale pokud by přicházela pošta od klienta s adresou 209.85.220.30, lze tuto adresu převést na jméno mail-fx0-f30.google.com a to zase zpět na adresu 209.85.220.30. To je zcela v pořádku. Není proto problém, aby taková zpráva vyhověla následujícímu pravidlu:

smtpd_client_restrictions =
  permit_mynetworks,
  check_sender_access hash:/etc/postfix/access,
  reject_unknown_client_hostname,
  permit

reject_unknown_client_hostname udělá přesně takový test, jaký je popsán výše, tedy převede IP adresu na jmennou a zpět. Kontroluje úspěšnost obou převodů a také to, zda se dostane zpět k původní adrese (jinými slovy, zda si DNS záznamy vzájemně odpovídají). Pokud kterákoli část selže, je klient odmítnut.

Problém spočívá v tom, že mnoho poštovních serverů nemá správně nastaven PTR záznam, případně ho nemá nastaven vůbec. Takové servery by byly při pokusu předat zprávu (byť zcela legitimní) odmítnuty. Proto je lepší se pravidlu raději vyhýbat, pokud záleží na doručení všech legitimních zpráv. Alternativně lze také místo reject_unknown_client_hostname použít reject_unknown_reverse_client_hostname, což je měkčí test, který kontroluje pouze existenci (jakéhokoli) PTR záznamu pro IP adresu klienta – ovšem i tento test může být v praxi příliš přísný.

Nyní se vrátím ještě k tomu, co dělá Google špatně. Podle RFC 2821 musí být veškeré doménové názvy používané v SMTP komunikaci (kromě dvou výjimek, ale to není tento případ) plně kvalifikovanými názvy převoditelnými na IP adresy, ať již přímo či nepřímo. Jenže Google uvádí v uvítací zprávě název mx.google.com, který žádný DNS záznam nemá. To je samozřejmě v rozporu s RFC 2821. Je dost možné, že server takto hlásí svůj název i v příkazu HELO/EHLO, figuruje-li v relaci jako klient. Kdo by chtěl takovým serverům vyhlásit válku, může tak učinit:

smtpd_helo_restrictions =
  reject_invalid_helo_hostname,
  reject_non_fqdn_helo_hostname,
  reject_unknown_helo_hostname,
  permit

Tyto tři kontroly testují nejprve to, zda je poskytnutý název formálně platný, dále zda je plně kvalifikovaným doménovým jménem a nakonec jeho existenci (ve smyslu existence A nebo MX záznamu). V praxi ale jde o další z kontroverzních restrikcí, která sice odstřihne nemálo spammerů, ale současně i docela dost legitimních odesílajících poštovních serverů a asi drtivou většinu klientů. Určitého změkčení by se dosáhlo přesunem uvedených kontrol do smtpd_recipient_restrictions a umístěním za permit_sasl_authenticated a před reject_unauth_destination (tím by se docílilo toho, že autentizovaných klientů by se kontrola netýkala), ale i tak by šlo stále o hodně „ostrou“ záležitost s velkou potenciální škodou a diskutabilním přínosem.

Při použití reject_non_fqdn_helo_hostname je možná zbytečné používat současně i reject_invalid_helo_hostname, protože většinu neplatných jmen vyloučí podmínka, že musí jít o plně kvalifikované doménové jméno. Zdálo by se, že při použití reject_unknown_helo_hostname jsou zbytečné obě předchozí kontroly, ale není tomu tak – mohou totiž výrazně zrychlit vyhodnocení, protože eliminují DNS dotazy na nesmyslné názvy. Kromě toho jde u neplatných názvů o permanentní chybu (hlášenou stavovým kódem 5xx), kdežto neexistence domény je chyba dočasná (kód 4xx), takže by to mohlo vést i ke zbytečným opakovaným pokusům o doručování ze špatně nastavených serverů. Toto platí obecně, i pro jiné typy kontrol, než je tato.

Jednoduché kontroly hlaviček a těla

Postfix sám neobsahuje žádné prostředky pro kontrolu obsahu hlaviček a těla zprávy. Podporuje ovšem takové nastavení, aby šlo kontrolu provádět jinde. Jednoduché kontroly lze implementovat pomocí regulárních výrazů, tedy bez nutnosti zapojovat do akce externí programy nebo služby. Kontrolu provádí služba cleanup, kontroluje se před vložením zprávy do fronty příchozích zpráv.

Již předem je třeba říct, že možnosti takové kontroly nejsou příliš velké, byť nejsou zanedbatelné. Problémem je hlavně to, že jde vždy o rozhodování, zda se zpráva přijme, či odmítne (případně se s ní provede nějaká jiná akce, například se zahodí, přesměruje nebo se pozmění její obsah). Není možné zprávu obodovat a pak výsledek kontroly posuzovat společně s výsledky jiných kontrol (třeba blacklistů). Tady je příklad nastavení:

header_checks = pcre:/etc/postfix/header_checks
body_checks = pcre:/etc/postfix/body_checks

V takovémto nastavení bude Postfix provádět kontrolu všech hlaviček (jednu pod druhé) a všech řádků těla (opět jeden po druhém), a to podle regulárních výrazů se syntaxí jazyka Perl. Výrazy jsou umístěny v souborech header_checks a body_checks. Místo pcre lze uvést také regexp, což jsou POSIX-kompatibilní regulární výrazy (jejich vyhodnocování je operačně náročnější, proto jsou preferovány výrazy v notaci Perl), případně jiný datový zdroj (v úvahu by přicházela externí služba, ovšem vzhledem k níže popsaným omezením je lepší externí kontrolu řešit jiným způsobem).

Aby kontrola fungovala, je třeba připravit příslušné regulární výrazy včetně akcí prováděných v případě, že zpráva výrazu vyhoví. Takto by mohl vypadat soubor header_checks:

/^Subject:(.*)viagra(.*)/ REJECT I don't need to improve erection
/^Content-(Disposition|Type).*name\s*=\s*"?(.*(\.|=2E)(bat|com|exe|pif|scr|vb[esx]?))(\?=)?"?\s*(;|$)/x
  REJECT This attachment type is prohibited

Soubor obsahuje dva výrazy. První kontroluje, zda se v hlavičce Subject (předmět zprávy) nenachází slovo Viagra (napsané libovolnou kombinací malých a velkých písmen – ve výchozím stavu výraz nerozlišuje velikost písmen) – pokud tam slovo je, je přijetí zprávy odmítnuto s patřičným odůvodněním. Druhý výraz kontroluje, zda není ke zprávě přiložen soubor zakázaného typu, přesněji řečeno se zakázanou příponou (zde jsou zakázány typické soubory, přes něž se šíří malware spustitelný v systému Windows).

Místo REJECT (odmítnutí zprávy) by bylo možné použít jinou akci, například DISCARD pro přijetí a zahození zprávy, PREPEND pro předřazení textu (vhodné hlavně pro hlavičku Subject, kam se předřadí informace o spamu) nebo WARN pro záznam zprávy do logu (vhodné pro ladění před použitím ostřejších akcí). Podobným způsobem jako pro hlavičky se připraví i soubor pro kontrolu těla zprávy (body_checks). Není na tom nic složitého:

/viagra/ REJECT I don't need to improve erection
/bank\ hong\ kong/ REJECT Good bye, Mr. Chang

Koho by více zajímala problematika tvorby regulárních výrazů pro Postfix, najde potřebné informace na manuálové stránce pcre_table(5) a samozřejmě v různých informačních zdrojích o tvorbě regulárních výrazů v obecné rovině. Ještě pro úplnost se sluší uvést, že existují ještě další dvě pravidla pro Postfix, kterými lze upravit kontroly hlaviček. Standardně se všechny hlavičky kontrolují stejně, nicméně lze použít parametry mime_header_checks (hlavičky MIME) a nested_header_checks (hlavičky zpráv vložených uvnitř zprávy) pro specifikaci jiných kontrol pro uvedené případy.

Takovéto řešení kontroly zpráv je samozřejmě dost omezené (jak z hlediska možností kontroly, tak i reakcí na nálezy) a obtížně spravovatelné. Má i další nevýhody, například to, že nedekóduje hlavičky ani tělo (zakódované pomocí BASE64 nebo quoted-printable), jednotlivé kontroly nelze dávat do souvislostí (například že něco platí jen při splnění jiné podmínky), tělo se kontroluje po řádcích (nelze hledat texty jdoucí přes dva nebo více řádků) nebo že při rozsáhlejších souborech s výrazy je vyhodnocení operačně velmi náročné a tedy pomalé. Proto je vhodné hledět na tyto kontroly jen jako na nouzové řešení pro případy, kdy nic lepšího nelze použít.

Antispam s použitím pomocníků

Mnohem více síly při boji se spamem a malwarem lze získat, pokud se k Postfixu přidají ještě další „pomocníci“. Existují programy, které mohou s Postfixem úspěšně spolupracovat při řešení různých úkolů při eliminaci nevyžádané pošty i různé nevítané havěti ve zprávách. Představí se v příštím dílu seriálu.

       

Komentáře

[trekker.dk]

Co je na greylistingu kontroverzního? Několikaminutové zpoždění snad nikoho nezabije (a co se zahraničních odesílatelů týče, tak z různých IP odesílá snad jenom Google a Facebook.)

[Max]

To si jen myslíš . Greylisting třeba u nás není vhodné nasadit. Čím větší zpožďování emailů, tím je to horší. Obchoďáci apod. by nás asi pak zabili :-/. Všechno musí být hned. Osobně se jim ani nedivím. Taktéž bych nechtěl čekat na odpověď o 10min déle. Obzvláště, pokud jde o nějakou urgentní záležitost. Ano, GreyL se použije jen při první komunikaci, ale vesměs se dost komunikuje s novými emailovými adresami, je to hodně živý, takže smolík :-/, zpožďování by bylo hodně časté.
Zdar Max

[Dušan Hokův]

greylisting je vyborna vec napr. na sekundarni mx, odfiltruje to spolu s blacklisty typu spamcop, abuseat vetsinu pokusu o spamovani

[mrak]

Ono nekolika minutove zpodeni zalezi na nastaveni intervalu prochazeni fronty, coz muze byt i hodina. Mimoto nektere zname servery od Vas vezmou v ramci greylistingu par zprav za urcity casovy usek, coz muze znamenat, ze email pro par stovek osob se dorucuje klidne i druhy den.

Take jsem se setkal s situaci, kdy domena mela nekolik mx s greylistingem a jeden nas vytrvale odmital akceptovat.

Technologie zajimava, ale moc me neoslovila.

[trekker.dk]

Mimoto nektere zname servery od Vas vezmou v ramci greylistingu par zprav za urcity casovy usek, coz muze znamenat, ze email pro par stovek osob se dorucuje klidne i druhy den.

Hm, nebo taky vůbec, pokud jde třeba o jeden velmi známý český skorogoogle.

[Jan Marek]

Mám dvě poznámky:

1) Posílat jeden mail stovce lidí bez použití mailing listu je zhovadilost a sama o sobě zavání spamem, byť se jedná o věc tak "nevinnou" jako vánoční přáníčko.

2) Greylisting může fungovat i tak, že pokud je po uplynutí greylistové doby z dané e-mailové a IP adresy doručen někomu konkrétnímu mail, pak je doručen třeba i dalším příjemcům, a to s přeskočením greylistu. Musím říct, že trošku vařím z vody, ale IMHO podstata greylistingu spočívá v tom, že se zjišťuje, zda dotyčná IP používá skutečný mailer, nebo jen jednorázového klienta. Jednorázový klient nemá frontu, takže zprávy podruhé nedoručuje, kdežto mailer frontu má a zprávy doručí. Takže když zjistím, že na daném IP je skutečný mailer, můžu od něj poštu pustit i někomu jinému, a to už bez zdržení. Tak mi velí logika věci.

Zdraví

Honza Marek

[petr]

ad1) odhledneme od Vanocniho pranicka - cou je dle meho proste spam... ale co treba takove temer kazdodenni informovani partneru na zmenu ... neceho. coz se bezne resi mailem s nekolika stovkami prijemcu pomoci bc:.

PS: osobni postesk: a to je pak fakt sranda kdyz je z toho 40% seznam.cz positive domain, zatim jsem se nesetkal s tak priserne spatnym mailserverem jako je seznam. s velkym odstupem druhy je hotmail . nejvice mne mrzi ze lide ani nechapou co je na mailu u seznamu spatne. je az zarazejici ze treba centrum.cz ci google.com jsou celkem v pohode... takze to nastavit nejak rozumne urcite jde... a to v malem i velkem :)

[obrazkovy spam]

No, pouzivat kontrolne sucty pre obrazkovy spam je dnes totalne na hovno. V obrazku ktory sa posiela sa vzdy zmeni par pixelov co ludske oko nepostrehne,ale kontrolne sucty to zmeni zasadne

[Luk]

Není to vždy. Samozřejmě, že se spammeři snaží přelstít jakákoli opatření, která jsou proti nim namířena. Nicméně to rozhodně není tak, že by na ně reagovali vždy, to se týká i těch obrázků.

[motyq]

na obrazky je proto treba pouzivat hashovaci funkce ktere pri male zmene vstupu malo zmeni kontrolni soucet :) zkuste se podivat na ssdeep, docela zajimave s tim jdou porovnavat obrazky

[Kvakor]

No, nevím, jak se to vyrobná s obrázky, které jsou zdeformované ve stylu Salvatora Dalího, takže člověk musí při čtení otáčet hlavou, aby přečetl, co je vlastně v tom mailu napsáno. V poslední době jsem několik takových dostal a mám pocit, že deformace byla u každého z nich odlišná bohužel jsou už všechny smazané). Nejspíš spameři používají mnohem více sílu procesoru v zombifikovaných strojích, takže si mohou dovolit udělat pro každý obrázek specifickou deformaci.

[odesilajici]

Posta z klientskych aplikaci se ma zasadne odesilat pres port 587. Port 25 je pro komunikaci server-server. Na portu 587 se po autentikaci/autorizaci pres TLS akceptuje libovolna adresa prijemce a bez autentikace/autorizace zadna (ani mistni). Na portu 25 se akceptuji pouze mistni prijemci. Tak je to podle doporucenych standardu - RFC 2476. Prosim autora, aby to vyslovne zminil, protoze jedine tak je to do budoucna spravne.

[Luk]

Posta z klientskych aplikaci se ma zasadne odesilat pres port 587. Port 25 je pro komunikaci server-server.

Ano, správně by to tak být mělo, ale bohužel není. Servery naslouchají až na výjimky jen na portu 25, klientské programy mají také jako výchozí nastaven tento port.

Prosim autora, aby to vyslovne zminil, protoze jedine tak je to do budoucna spravne.

Zmínit to mohu (ostatně kdysi už se tu o tom docela vydatně debatovalo), nicméně je to klasický problém slepice-vejce. Takže v klientech to tak není, protože servery sedí standardně jen na portu 25, kdežto u serverů se nechává jen port 25, protože je to tak v klientech. Mělo by se to rozseknout, ale zatím to nevypadá, že by se do toho někdo (když nepočítám Google, ten to snad používá) masově pouštěl.

[odesilajici]

To se pletete. O zadny problem slepice - vejce nejde. Vsechny dnes normalne dostupne klentske programy umi autentikaci na portu 587. Dokonce vsechny produkty mrkvosoftu od Outlook Expressu ve Windows XP a Outlooku z Officu 2003 umi TLS autentikaci na portu 587 - to vim na 100% (plne ozaplatovane). S Officem 2000 a XP uz jsem dlouho neprisel do styku, ale da se dogooglit, ze umi autentikaci na portu 587. I kdyby neumely TLS, stale je to lepsi nez nechat odesilat vlastni lidi pres port 25. Prinejmensim se mnohem lepe vytvari ruzne sady pravidel pro ruzne porty.

P.S. myslel jsem, ze pisete, jak to ma byt, ne jak to delaji nemehla ;)

[Luk]

Vsechny dnes normalne dostupne klentske programy umi autentikaci na portu 587. Dokonce vsechny produkty mrkvosoftu od Outlook Expressu ve Windows XP a Outlooku z Officu 2003 umi TLS autentikaci na portu 587 - to vim na 100% (plne ozaplatovane).

Netvrdím, že to neumí (ten OE to umí dokonce i přes to, že pro POP3 a IMAP umí jen obyčejné SSL/TLS, nikoli STARTTLS). Tvrdím však, že mají jiné výchozí nastavení, tedy port 25.

P.S. myslel jsem, ze pisete, jak to ma byt, ne jak to delaji nemehla ;)

Píšu, jak je to v reálném světě. Netýká se to jen tohoto. Správně by tak neměl být problém blokovat poštu ze strojů, pro které není korektně nastaven DNS záznam. Jenže v praxi to problém je, možná i více než polovina pošty by nebyla doručena, protože zdaleka ne pro každý server je to nastaveno správně. Podobně třeba způsob deklarace podporovaných autentizačních metod SASL (snad už se Microsoft polepšil, ale starých klientů bohužel stále žije dost).

Proto by sice bylo hezké říkat "nastavte si to takhle, jedině tak je to správně podle RFC", jenže to vygeneruje spoustu problémů, až to BFU nebudou umět v klientech nastavit. Tedy říkám, že to zmíním, ale s tím, že takové nastavení může přinést problémy. A opakuji, už jsme to tu kdysi řešili, není to nic nového.

[odesilajici]

Moc vasi averzi vuci portu 587 nerozumim. Popisujete, jak zmenit vychozi nastaveni postfixu aby tohle jo a aby tamhleto ne, proc nepopsat i nastaveni aby port 587 jo? I kdybyste mel pripsat dalsi kapitolu. Dle mych zkusenosti je dnes vetsi problem u externich pristupu odesilat pres port 25 nez pres port 587 (kvuli blokaci ci presmerovani portu 25 u ruznych mensich provideru). Jedine, co nezajistite konfiguraci postfixu je pitomy antivir na klientech. Ale to plati i pro TLS na portu 25. Nicmene vy jste autor, je to na vas. Alespon zminku o doporucenem nastaveni si to urcite zaslozi.

[Luk]

Moc vasi averzi vuci portu 587 nerozumim. Popisujete, jak zmenit vychozi nastaveni postfixu aby tohle jo a aby tamhleto ne, proc nepopsat i nastaveni aby port 587 jo?

Ale proboha, copak říkám, že to nepopíšu?

Dle mych zkusenosti je dnes vetsi problem u externich pristupu odesilat pres port 25 nez pres port 587 (kvuli blokaci ci presmerovani portu 25 u ruznych mensich provideru).

To je pravda, ale blokace nebo dokonce přesměrování portu (kteréhokoliv) je mnohem větší prasárna, než odesílat poštu přes port 25.

Alespon zminku o doporucenem nastaveni si to urcite zaslozi.

Bude.

[odesilajici]

ok, ok, uz mlcim. Ja jen, ze jsem to pochopil tak, ze bude zminka, ze port 587 se da, ale je to problematicke, tecka. Pokud bude popis, bude to zasluzne. S presmerovanim portu souhlas, ale to neovlivni ani cestujici s klientskou aplikaci ani spravce postovniho serveru.

[Mortal]

Jenom male upresneni:
rfc2476 obsoleted by rfc4409
tot vse, co jsem zlehka porovnal tu cast s portem 587, je tam jen lingvisticka zmena