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í
×
včera 21:55 | Zajímavý článek

Vláda v pondělí 13. července projednala Výroční zprávu o stavu otevřených dat za rok 2019. Ke stažení je na Portálu otevřených dat (pdf).

Ladislav Hagara | Komentářů: 0
včera 16:22 | Komunita

MojeFedora.cz informuje, že FESCo schválilo návrh, aby se jako výchozí editor v terminálu od Fedory 33 používalo GNU nano. Fedora doteď žádný výchozí editor pro terminál nastavený neměla a nechávala to na jednotlivých programech. Ty často používané, jako třeba git, ale ve výchozím stavu používaly editor vi, který autor návrhu nepovažuje za příliš intuitivní.

Ladislav Hagara | Komentářů: 11
včera 14:22 | Komunita

Dlouhodobá LTS podpora Debianu 8 Jessie vydaného 26. dubna 2015 skončila k 30. červnu 2020. K dispozici je placená rozšířená dlouhodobá podpora ELTS do 30. června 2022. Poslední opravné vydání Debianu 9 Stretch uvolněného 17. června 2017 bude vydáno 18. července 2020. Jeho dlouhodobá podpora je plánována do 30. června 2022. Plánujete-li ji využívat, vývojáři ocení vyplnění dotazníku ohledně této LTS podpory.

Ladislav Hagara | Komentářů: 2
včera 06:00 | Nová verze

Byla vydána nová verze 1.26.0 sady nástrojů pro správu síťových připojení NetworkManager. Novinkám se v příspěvku svém na blogu věnuje Thomas Haller.

Ladislav Hagara | Komentářů: 2
13.7. 13:00 | Zajímavý software

Laboratoře CZ.NIC zveřejnily software DNS Probe. Jeho úkolem je zachycovat DNS provoz na síťovém rozhraní (UDP i TCP), párovat DNS dotazy s příslušnými odpověďmi a exportovat konsolidované záznamy o každé jednotlivé DNS transakci, která se v síťovém provozu vyskytla.

Ladislav Hagara | Komentářů: 0
13.7. 08:00 | Nová verze

Byla vydána verze 2.2.0 svobodného softwaru HAProxy (The Reliable, High Performance TCP/HTTP Load Balancer; Wikipedie) řešícího vysokou dostupnost, vyvažování zátěže a reverzní proxy. Detailní přehled novinek v příspěvku na blogu společnosti HAProxy Technologies.

Ladislav Hagara | Komentářů: 2
13.7. 01:11 | Nová verze

Správce oken IceWM (Wikipedie) byl vydán ve verzi 1.7.0. Přehled novinek, vylepšení a oprav na GitHubu.

Ladislav Hagara | Komentářů: 9
12.7. 01:22 | Komunita

Před dvěma lety se Andrew Kelley rozhodl naplno věnovat se svému koníčku, tj. vývoji open source programovacího jazyka Zig (GitHub). Opustil své dobře placené místo v OkCupid a vytvořil si účet na Patreonu. Včera představil nadaci Zig Software Foundation zastřešující propagaci a další vývoj tohoto programovacího jazyka. Podpořit ji lze na GitHub Sponsors (aktuálně 66 % z měsíčního cíle 8 600 $).

Ladislav Hagara | Komentářů: 3
11.7. 22:11 | Nová verze

Byla vydána verze 2.0.10 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Nově využívá nedávno vydaný Free Pascal Compiler (FPC) 3.2.0.

Ladislav Hagara | Komentářů: 13
11.7. 13:00 | Komunita

Letošní konference linuxových instalatérů Linux Plumbers Conference (LPC 2020) proběhne online ve dnech 24. až 28. srpna. Vývojáři Linuxu by měli probírat také podporu programovacího jazyka Rust v linuxovém jádru [Hacker News].

Ladislav Hagara | Komentářů: 0
Používáte některé open-source řešení [protokol] pro šifrovaný instant messaging?
 (22%)
 (31%)
 (4%)
 (11%)
 (17%)
 (5%)
 (13%)
 (24%)
Celkem 350 hlasů
 Komentářů: 39, poslední včera 00:13
Rozcestník

Už je to tu zas - "nejde vám mail"

29.4.2009 09:11

Znáte to: někdo zavolá, "přišlo Vám to?" - "nepřišlo" - "vždyť jsem to odesílal". Ti bystřejší zavolají rovnou "poslal jsem Vám to ale vrátilo se to".

Pak se kouknu do logu na serveru a tam jsou věci typu Helo command rejected: Host not found. Ach jo. Ano, zkouším to, pravidelně v intervalu cca 3-5 let, zda mi projde, když si nastavím SMTP server na striktní režim. Neprojde. A to jsou prosím maily od velké společnosti se solidním zázemím.

Takže hlavně žádné restrikce - i kdyby na port 25 přišel HTTP dotaz, tak ho doručit jako mail...

       

Hodnocení: 100 %

        špatnédobré        

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

Komentáře

Vložit další komentář

29.4.2009 10:27 Zdenek
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"
Mno ja mam to stesti, ze jsem v te velke spolecnosti a muzu diktovat tem malym jak maji mit nastavene mailservery ;-)
29.4.2009 11:30 tezkatlipoka | skóre: 35
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"

velke spolecosti jsou pakaz, jedna velka mezinarodni nam  zacala kdysi zahazovat emaily, po nekolika dennim prudění jsme přisli na to, ze je to proto, ze si nastavili tak přisnou kontrolu obsahu, ze slovo podpis povazovali za sproste, a ani chybejici s je nepřesvědčilo o opaku. Nastesti jsem tam pak narazil na jednoho admina puvodem polaka, ktery jim to potvrdil. Ale uzili jsme si to, už proto ze tato firma maily rovnou zahazovala, takze jsme zprvu vubec nevedeli ze se neco deje.

Vaše řeč budiž ano, ano, ne, ne. Co je nad to, je od ďábla.
29.4.2009 12:56 Zdenek
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"
Jo zahazovani bez informovani je hnus, nejlepsi je odmitnout mail jiz behem SMTP spojeni.
29.4.2009 16:22 Zdeněk Burda | skóre: 61 | blog: Zdendův blog | Praha
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"
Některé velké společnosti na to nehezky serou:

Received: from mtagate8.de.ibm.com (mtagate8.de.ibm.com [195.212.29.157])
 (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mail.xxx.xxx (Postfix) with ESMTP id B725A4B268
 for <xxx@xxx>; Tue, 28 Apr 2009 22:48:40 +0200 (CEST)
Received: from d12nrmr1607.megacenter.de.ibm.com
 (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49])
 by mtagate8.de.ibm.com (8.14.3/8.13.8) with ESMTP id n2OEakTW228592
 for <xxx@xxx>; Tue, 24 Mar 2009 14:36:46 GMT


-- Nezdar není hanbou, hanbou je strach z pokusu.
29.4.2009 10:40 Kvakor
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"
Dle RFC 2821 by se měl mailserver v HELO/EHLO představit kanonickým a resolvovatelným (nejlépe i zpětně resovovatelným) jménem stroje a pokud není dostupné, tak má alespoň použít svou aktuální adresu a ne nějaký nesmysl typu NAVUQLM. Pokud máte tu smůlu, že zrovna z takovéhoto humpolácky nastaveného mailserveru musíte přijímat poštu, tak je lepší ho dát do whitelistu než všechno globálně povolit, ušetříte si spoustu starostí se spamem.
29.4.2009 11:36 Chulda | skóre: 20
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"
Ale uzije si spoustu "srandy" s obchodniky. Kolegove by moyhli vypravet :(
29.4.2009 13:22 Kvakor
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"
Vetšinou stačí přes dotčného vzkázat administrátorovy mailserveru, že má chybně nakonfigurovaný server.
29.4.2009 19:13 Marv-CZ | skóre: 21
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"

Na to vám zaručeně příjde odpověď:

"Ostatním to od nás chodí, takže chyba je u Vás."

30.4.2009 08:11 Filip Jirsák | skóre: 67 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"
Ovšem bylo by dobré to poslat především tomu, kdo ho má nakonfigurovaný opravdu chybně, tedy v rozporu s RFC -- v tom to případě tedy nejprve autorovi blogu.
29.4.2009 13:49 Filip Jirsák | skóre: 67 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"
Správně píšete „má“ (lépe řečeno „měl by“). V originále SHOULD, což znamená doporučení, přičemž existují případy, kdy je přípustné takové doporučení ignorovat. Pokud tedy někdo v HELO/EHLO požaduje kvalifikované doménové jméno odesílajícího stroje, má chybně nakonfigurovaný server především on. Hlavně že se tou chybnou konfigurací nezapomene pochlubit v blogu…
29.4.2009 16:52 Kvakor
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"
Kdepak, pokud SMTP server odmítne komunikovat s jiným serverem, který porušuje nepoviné částí (SHOULD) rozličných RFC, tak se to dá považovat za všechno možné, jen ne chybnou konfiguraci. Obecně totiž server může odmítnou komunikaci z libovolného důvodu, ale pokud to udělá dle pravidel SMTP protokolu, je to stále v pořádku.

Jinak kontrolu kvalifikovaného doménového jména (FQDN) odesílajícího serveru (ještě spojenou s kontrolo existence reverzního DNS záznamu) považuju za velmi účinnou zbraň, kterou se zastaví takových 95% spamu pocházejícího z botnetů.

Korekntí servery, které nemají FQDN, nebo vrací v HELO/EHLO blbosti (naprosté minimu), sice také neprojdou, ale zkusí další MX záznam, kde je server providera a ten už žádné kontroly nemá. Takže legitimní e-mail dorazí (protože u SMTP server MUSÍ zkusit další MX záznam), ale spam neprojde.
29.4.2009 17:35 Filip Jirsák | skóre: 67 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"
Kdepak, pokud SMTP server odmítne komunikovat s jiným serverem, který porušuje nepoviné částí (SHOULD) rozličných RFC, tak se to dá považovat za všechno možné, jen ne chybnou konfiguraci. Obecně totiž server může odmítnou komunikaci z libovolného důvodu, ale pokud to udělá dle pravidel SMTP protokolu, je to stále v pořádku.
Jistě, server může odmítat e-maily třeba od lidí, kteří se na jeho správce špatně podívali. Ale pak neplní správně svou funkci -- poštovní server má za úkol doručit maximum e-mailů, nikdo od něj nechce, aby některé e-maily náhodně zahazoval.
Jinak kontrolu kvalifikovaného doménového jména (FQDN) odesílajícího serveru (ještě spojenou s kontrolo existence reverzního DNS záznamu) považuju za velmi účinnou zbraň, kterou se zastaví takových 95% spamu pocházejícího z botnetů.
Další, kdo řekne polovinu informace, a skončí. Účinnost spam filtru můžete posuzovat jedině podle poměru (správně) odmítnutých spamů a (nesprávně) odmítnutých hamů. Pokud to posuzujete jen podle odmítnutého spamu, vypněte si mailserver -- to je ten nejlepší způsob boje proti spamu, zastaví to zaručeně 100 % spamu.
29.4.2009 19:34 Zdenek
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"
Ja mam jednodusi metodu posuzovani. Podle reakci uzivatelu pro ktere mailserver spravuji :-)
30.4.2009 07:44 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"
poštovní server má za úkol doručit maximum e-mailů, nikdo od něj nechce, aby některé e-maily náhodně zahazoval
Poštovní server má za úkol udělat to, k čemu je nastaven. Pokud ho nastavím aby něco zahazoval, tak to bude zahazovat.
Účinnost spam filtru můžete posuzovat jedině podle poměru (správně) odmítnutých spamů a (nesprávně) odmítnutých hamů.
K tomu mohu říci, že po uvolnění restrikce abych přijmul ten jeden celkem důležitý ham mail, jsem zároveň obdržel řádově 20 spamů.
In Ada the typical infinite loop would normally be terminated by detonation.
30.4.2009 08:09 Filip Jirsák | skóre: 67 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"
Poštovní server má za úkol udělat to, k čemu je nastaven. Pokud ho nastavím aby něco zahazoval, tak to bude zahazovat.
Ale pokud si server nastavíte tak, aby odmítal komunikaci, kterou RFC připouští, nesvádějte pak odmítání e-mailů na to, že RFC porušuje druhá strana.
30.4.2009 08:28 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"
K tomu mohu říci, že po uvolnění restrikce abych přijmul ten jeden celkem důležitý ham mail, jsem zároveň obdržel řádově 20 spamů.
OK, takže jsou dvě varianty - buď zavedu restrikci a uživatelům nebude přicházet pošta, nebo ji uvolním a naložím o trochu víc práce spamfiltru... hm

Ale fajn, s tebou jsou přeci uživatelé spokojení - asi proto, že neví (stejně jako ty), o kolik mailů vlastně přišli.
Quando omni flunkus moritati
30.4.2009 18:17 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"
Já mám jen jednoho uživatele - sebe - a spokojený jsem. Navíc spam filtr nemám, protože když ten něco vyřadí tak o tom nevíte úplně stejně. To je lepší těch 30 spamů denně smazat, než denně hledat ve složce s 30 spamama jestli tam není nějaký normální mail.
In Ada the typical infinite loop would normally be terminated by detonation.
30.4.2009 22:28 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"
Navíc spam filtr nemám, protože když ten něco vyřadí tak o tom nevíte úplně stejně.
Jo, proto má spamassassin možnost jenom přepsat subject...
Quando omni flunkus moritati
1.5.2009 07:43 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"
A když se nad tím zamyslíte podrobněji, tak to vyrobí tentýž problém.
In Ada the typical infinite loop would normally be terminated by detonation.
30.4.2009 18:24 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"
Takže legitimní e-mail dorazí (protože u SMTP server MUSÍ zkusit další MX záznam), ale spam neprojde.

To je docela dobrý nápad, asi to nastavím takto. Budu to ale ještě muset sladit s nolistingem, jelikož se zase dostanu do konfliktu s tím, že nějaké dementní SMTP servery zkusí jen dva a né tři MX.
In Ada the typical infinite loop would normally be terminated by detonation.
30.4.2009 07:40 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"
V originále SHOULD
Opravdu?
-  The domain name given in the EHLO command MUST BE either a primary
   host name (a domain name that resolves to an A RR) or, if the host
   has no name, an address literal as described in section 4.1.1.1.
existují případy, kdy je přípustné takové doporučení ignorovat
Tak mi prosím nějaký uveďte a obhajte ho jako případ kdy server připojený k síti s veřejnou adresou, společnost má kontrolu nad svým DNS atd., prostě normálně, má důvod něco takového dělat.

In Ada the typical infinite loop would normally be terminated by detonation.
30.4.2009 08:03 Filip Jirsák | skóre: 67 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"
V originále SHOULD
Opravdu?
Opravdu. Přímo u příkazu EHLO je totiž toto:
These commands are used to identify the SMTP client to the SMTP server. The argument field contains the fully-qualified domain name of the SMTP client if one is available. In situations in which the SMTP client system does not have a meaningful domain name (e.g., when its address is dynamically allocated and no reverse mapping record is

available), the client SHOULD send an address literal (see section 4.1.3), optionally followed by information that will help to identify the client system.
existují případy, kdy je přípustné takové doporučení ignorovat
Tak mi prosím nějaký uveďte a obhajte ho
Moje úloha jako příjemce není zkoumat, jaké má odesílatel důvody. RFC tuhle variantu připouští, tak s ní musím počítat. Nebo řekněte, že na RFC kašlete a uděláte si to po svém -- pak ale netvrďte, že RFC porušuje ten druhý.
30.4.2009 18:14 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"
Přímo u příkazu EHLO je totiž toto: ...
Vždyť to je totéž co jsem psal já! Musí tam být buď smysluplné jméno nebo IP adresa. To Vaše RFC nepřipouští situaci že tam je jméno které nejde resolvovat - což je případ kdy to pak mail server odmítne, je-li nastaven "striktně".

A navíc jsem nikde o žádném porušování RFC nic nepsal. Já jsem psal jen to, že mě štve, že SMTP komunikace neprochází základními "sanity" kontrolami, zkrátka že mi ty servery posílají blbosti, přitom není problém pro daného správce to nastavit dobře (navíc by to měla být jeho psí povinnost). Nějakým RFC jste tu začal šermovat až Vy a navíc nepravdivě.
In Ada the typical infinite loop would normally be terminated by detonation.
1.5.2009 00:37 Dračík | Kladno
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"

Souhlasím s Filipem Jirsákem. V RFC 5321 se říká toto:

An SMTP server MAY verify that the domain name argument in the EHLO command actually corresponds to the IP address of the client. However, if the verification fails, the server MUST NOT refuse to accept a message on that basis.

Každý si samozřejmě může nastavit MTA jak chce, ale chtěl bych vás vidět, jak ve firmě před managementem obhajujete, že zahazujete maily od zákazníků, ať máte sebevětší pravdu, že jsou prasata a neumí (nebo nemůžou) si to nastavit ;-)

1.5.2009 07:51 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"
V tom 5321 je ale tatáž pasáž o tom jak to EHLO má vypadat (viz výše). A já se nebavím o souhlasu s IP adresou klienta ale o tom, že hostname uvedený v HELO/EHLO nemá žádnou adresu. A opět opakuji: můj blog post je o tom, že to je bordel a nezkoumám to verzus nějaké RFC. Ono to ani není potřeba, protože normální poučka zní, že server by měl akceptovat všelicos, dokud to ještě dává smysl.
ve firmě před managementem
Opět opakuji: je to můj soukromý server s jedním uživatelem (mnou). A jinak si dovedu představit i firmu, která by to v rámci možností oficiálně prosazovala - je to podobné jako prosazovat aby Vám nechodily v přílohách docy apod.
In Ada the typical infinite loop would normally be terminated by detonation.
1.5.2009 09:52 Filip Jirsák | skóre: 67 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"
Ono to ani není potřeba, protože normální poučka zní, že server by měl akceptovat všelicos, dokud to ještě dává smysl.
Což je v rozporu s vaším „nastavením serveru na striktní režim“. Takže by se ten váš zápisek taky dal výstižněji formulovat jako: „Porušil jsem známé pravidlo, že odesílatel má být přísný v tom, co odesílá, a příjemce tolerantní v tom, co přijímá – a narazil jsem.“ Jenže pak by musel následovat zcela opačný závěr – ne rýpnutí do „velké společnosti se solidním zázemím“, ale upozornění pro ostatní „neopakujte stenou hloupost, kterou jsem udělal já“.
1.5.2009 13:02 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"
No, ještě jste to úplně nepochopil ale jste na správné cestě. Zkuste si znovu ten zápisek přečíst.
In Ada the typical infinite loop would normally be terminated by detonation.
1.5.2009 13:27 Filip Jirsák | skóre: 67 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"
Přečetl jsem si to znova a chápu to pořád stejně – vy jste si na svém serveru nastavil nějaká pravidla, která jsou přísnější než RFC, a stěžujete si, že někdo jiný se těmito vašimi pravidly neřídí.
1.5.2009 14:00 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"
Nechme stranou RFC - stěžuju si na to, že když to tak nastavím, tak zjistím že existují entity, které nemají zjevný důvod ke špatnému nastavení a přesto špatným nastavením trpí. Navíc se domnívám, že nějaké RFC mají u něčeho, leda že byste u toho serveru seděl Vy osobně :-D
In Ada the typical infinite loop would normally be terminated by detonation.
xkucf03 avatar 1.5.2009 10:57 xkucf03 | skóre: 49 | blog: xkucf03
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"
A já se nebavím o souhlasu s IP adresou klienta…

Pak to ale nemá cenu řešit, alespoň z dlouhodobějšího hlediska – pokud nebudeš kontrolovat IP, je to na nic, protože spameři tam začnou cpát třeba seznam.cz.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
1.5.2009 13:04 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"
To je takové coby kdyby: oni by samozřejmě udělali úplně nejlépe, kdyby měli normální SMTP server, který by se nelišil od jiných. Ale to nemají, a seznam.cz tam také necpou, takže to zatím funguje. Až to přestane fungovat, sáhneme po něčem jiném.
In Ada the typical infinite loop would normally be terminated by detonation.
1.5.2009 09:44 Filip Jirsák | skóre: 67 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"
V RFC je napsáno, že za HELO/EHLO je název (všimněte si nepřítomnosti MUST). A pokud takový název nelze smysluplně vytvořit, měla by by tam být IP adresa (SHOULD). Stále ale existuje možnost, že název nelze smysluplně vytvořit a správce serveru se nebude řídit doporučení mít tam IP adresu (protože SHOULD je jen doporučení) – v takovém případě pak může být v EHLO cokoli (co splní syntaktická pravidla), žádné další pravidlo, co použít, když se nepoužije ani IP adresa, v RFC není.
A navíc jsem nikde o žádném porušování RFC nic nepsal. Já jsem psal jen to, že mě štve, že SMTP komunikace neprochází základními "sanity" kontrolami, zkrátka že mi ty servery posílají blbosti, přitom není problém pro daného správce to nastavit dobře (navíc by to měla být jeho psí povinnost). Nějakým RFC jste tu začal šermovat až Vy a navíc nepravdivě.
Psal jste, že jste blokoval komunikaci se servery, které mají podle vás chybné nastavení, ale to nastavení je v souladu s RFC. A vadilo vám, že tahle vaše pravidla nad rámec RFC někdo jiný nedodržuje. Jenže kdyby si každý vymýšlel svoje pravidla pro e-mailovou komunikaci, nebo to samozřejmě nikdy fungovat. Právě proto je tu RFC, kterým se mají řídit všichni – pokud se jím řídí obě strany komunikace, nenastává žádný problém.
1.5.2009 13:08 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"
všimněte si nepřítomnosti MUST
Buď těch RFC je tolik a navzájem si odporují, a nebo nevím co jiného je špatně ale já tam to MUST vidím.
Jenže kdyby si každý vymýšlel svoje pravidla pro e-mailovou komunikaci
Já si nic nevymýšlím, prostě jstem použil nějaké standardně dodávané nastavení a sledoval jsem, co se stane. Vymýšlí si spíše odesilatel, když si myslí, že smyslem parametru EHLO je něco, co neexistuje.
In Ada the typical infinite loop would normally be terminated by detonation.
1.5.2009 13:23 Filip Jirsák | skóre: 67 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"
všimněte si nepřítomnosti MUST
Buď těch RFC je tolik a navzájem si odporují, a nebo nevím co jiného je špatně ale já tam to MUST vidím.
Já teda ne:
These commands are used to identify the SMTP client to the SMTP server. The argument field contains the fully-qualified domain name of the SMTP client if one is available. In situations in which the SMTP client system does not have a meaningful domain name (e.g., when its address is dynamically allocated and no reverse mapping record is available), the client SHOULD send an address literal (see section 4.1.3), optionally followed by information that will help to identify the client system.
Já si nic nevymýšlím, prostě jstem použil nějaké standardně dodávané nastavení a sledoval jsem, co se stane. Vymýšlí si spíše odesilatel, když si myslí, že smyslem parametru EHLO je něco, co neexistuje.
Vymyslel jste si pravidlo, že parametr HELO/EHLO musí nějak vypadat. A on tak podle RFC vypadat nemusí, a vaše pravidla asi nikdo nezná.
1.5.2009 13:55 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"
Tak si zascrolujte výš, ta mnou citovaná pasáž je ze stejného dokumentu.
In Ada the typical infinite loop would normally be terminated by detonation.
1.5.2009 14:09 Filip Jirsák | skóre: 67 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"
Myslíte tohle?
The domain name given in the EHLO command MUST BE either a primary host name (a domain name that resolves to an A RR) or, if the host has no name, an address literal as described in section 4.1.1.1.
To se ale týká pouze toho, jak má vypadat doménové jméno předávané v příkazu EHLO. Neříká to nic o tom, zda v tom příkazu může nebo nemůže být nic jiného.
1.5.2009 16:14 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"
A co jiného by tam mělo být?
In Ada the typical infinite loop would normally be terminated by detonation.
1.5.2009 16:58 Filip Jirsák | skóre: 67 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"
Popis toho, jak má vypadat parametr EHLO v případě, kdy tam není ani doménové jméno ani IP adresa.
2.5.2009 09:33 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"
Nechápu. Co jiného než tyto dvě věci by mělo být parametrem EHLO?
In Ada the typical infinite loop would normally be terminated by detonation.
2.5.2009 11:04 Filip Jirsák | skóre: 67 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"
Definice EHLO říká, že jeho parametrem může být 1. doménový název, 2. IP adresa, 3. něco jiného. Vámi uvedená definice řeší, jak má ten název vypadat, pokud je zvolena varianta č. 1, případně jak má vypadat IP adresa, pokud je zvolena varianta č. 2. Co se má dít v případě varianty č. 3 se tam neřeší.
3.5.2009 13:31 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"
Co se má dít v případě varianty č. 3 se tam neřeší.
A kde se to řeší? :-)
In Ada the typical infinite loop would normally be terminated by detonation.
3.5.2009 13:36 Filip Jirsák | skóre: 67 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"
Nikde, je to na volné tvorbě – samozřejmě při zachování syntaktických pravidel.
3.5.2009 19:46 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"
No, a jaká jsou ta pravidla? Že to je FQDN nebo IP? :) Nic jiného z RFC nevyplývá, žádný jiný smysl ani ten příkaz nemá, a určitě by tam o tom nebyla celá pasáž, kdyby to bylo na libosti implementace. Pokud se chcete opírat o argument, že "contains" není "MUST", tak to nemá smysl dále rozebírat...
In Ada the typical infinite loop would normally be terminated by detonation.
3.5.2009 20:06 Filip Jirsák | skóre: 67 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"
No, a jaká jsou ta pravidla?
Že ta řádka neobsahuje CR nebo LF, je zakončena CRLF a má nejvýš 512 znaků.

„Contains“ skutečně není „MUST“, „SHOULD“ také není „MUST“. Celá pasáž je tam o případu, kdy obsahuje doménové jméno – ale definice EHLO připouští tři varianty: doménové jméno, pokud neexistuje rozumné doménové jméno, pak „SHOULD“ IP adresa, a z toho implicitně plyne, že existuje možnost „neexistuje rozumné doménové jméno a zároveň se nevyhoví tomu ‚SHOULD‘“. Pokud vy si myslíte, že autoři RFC chtěli napsat „MUST“ ale omylem napsali „SHOULD“, je to dost zvláštní výklad RFC…
3.5.2009 21:13 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"
Takže když dostanu EHLO s něčím, co má tvar FQDN, ale nemá adresu (A záznam), což je v rozporu s mnou citovanou pasáží, tak bych si měl říct: aha! on chtěl poslat správné FQDN, ale zrovna asi žádné neměl, tak si řekl, že IP adresu by poslat měl, ale vlastně nemusí, tak se na to rovnou vykašlal a neposlal FQDN ale náhodně vygenerovaný řetězec, který má nanejvýš 512 znaků, atd. a zrovna náhodou vypadá jako FQDN, které nemá A záznam. Tak to je také trochu svérázný výklad, nemyslíte?

Myslím si, že pokud by RFC nějakou třetí možnost připouštělo, tak by tam byla jednoznačně popsána. Implicitní možnosti, hlavně takové, které popírají smysl téže pasáže, se v takových dokumentech moc nenosí. Pokud chcete, zeptám se na to přímo autora nebo lidí co to RFC implementují.

A už vůbec nevidím důvod k tomu, aby k té nejednoznačné implicitní třetí variantě někdo nastavil svůj server.
In Ada the typical infinite loop would normally be terminated by detonation.
30.4.2009 12:56 melkors | skóre: 13 | blog: kdo_chce_kam
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"

"... společnost má kontrolu nad svým DNS ..."

A kdyz nema? Resp. ISP na nejake DNS z vysoka ...?

Znam takove priklady z vlastni praxe a vim, ze je potom docela problem s dorucovanim mailu - a to jsem si jen chtel nechat posilat denni vysledky watchlogu.

30.4.2009 13:37 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"

HELO má sloužit k identifikaci stran. Pokud tam klient pošle nějakou blbost, tak sice můžete spojení odmítnout (jako kdykoliv jindy), ale je to čistě z vaší zvůle, nikoliv kvůli porušení protokolu.

Že to někdo používá jako charakteristiku spammera, je fakt jeho nesprávná úvaha, která s sebou vezme i kvanta ostatní regulérní pošty.

Kdyby se ukázalo, že spammer posílá „helo“, kdežto stabilní stroje obvykle „HELO“, tak byste se tím taky řídil?

Co uděláte, když vám padne DNS resolver? Budete veškerou poštu odmítat?

30.4.2009 18:20 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"
která s sebou vezme i kvanta ostatní regulérní pošty.
Mám zkušenost opačnou. Hromada zamítnutého spamu (celkem zadarmo) ale občas i ten nějaký mail. Bohužel kvůli tomu jednomu, co si neumí nastavit server, musím přijímat i ty spamy.
Co uděláte, když vám padne DNS resolver? Budete veškerou poštu odmítat?
Tak jelikož je DNS součástí normálního fungování internetu, tak bude pošta jen jeden z mnoha problémů které nastanou. Nemluvě o tom, že pošta nepůjde zejména odesílat, tak korektní SMTP server při chybě DNS příchozí zprávy odmítá s kódem dočasné chyby, tj. přijde to později, až bude DNS fungovat.
In Ada the typical infinite loop would normally be terminated by detonation.
xkucf03 avatar 1.5.2009 00:50 xkucf03 | skóre: 49 | blog: xkucf03
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"

Na druhou stranu by to prakticky vyřešilo problém se spamem:

  1. vyžádat si plně kvalifikované jméno v EHLO
  2. najít si k němu MX záznamy
  3. pokud mezi nimi není IP adresa, ze které mail přichází, tak ho nepřijmeme

Spammeři by si museli pořizovat vlastní domény a posílat z IP adres ke kterým existují MX záznamy… neříkám, že by to nedělali, ale do blacklistů by se pak dostávaly rovnou celé jejich domény (ne jen IP adresy) a to by spam dost omezilo.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
1.5.2009 01:32 Dračík | Kladno
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"

No, a co když je odesílatel host a ne doména? Takový žádné MX záznamy mít nebude a zahazovat je přece taky nemůžete...

1.5.2009 07:53 pht | skóre: 48 | blog: pht
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"
To asi není úplně dobrý nápad, protože mail lze posílat přes různé relay, kde obecně nemusí sedět IP adresa odesílajícího serveru s IP adresou přijímajícího serveru.
In Ada the typical infinite loop would normally be terminated by detonation.
1.5.2009 09:47 Filip Jirsák | skóre: 67 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Už je to tu zas - "nejde vám mail"
V diskusi o spamu přijde pokaždé někdo s tímhle nápadem, a pokaždé je mu třeba vysvětlovat, že odesílání e-mailů s adresou odesílatele z nějaké domény nemusí mít zhola nic společného se serverem přijímajícím poštu pro tutéž doménu.
xkucf03 avatar 1.5.2009 11:21 xkucf03 | skóre: 49 | blog: xkucf03
Rozbalit Rozbalit vše Kontrola IP adres a DNS
  1. Což ale nebrání tomu, aby odesílací server (brána) měl také MX záznam, ale s tak nízkou prioritou, že na něj nikdy nedojde řada (a kdyby přece jen došla, mail může odmítnout a pak se za chvíli zkusí zase servery s vyšší prioritou).
  2. Není to systémově moc hezké řešení → takže by bylo dobré přidat typ DNS záznamu, který by říkal, že daná IP je oprávněna použít toto doménové jméno v HELO/EHLO
  3. Pokud bychom chtěli být opravdu radikální, mohli bychom vyžadovat shodu mezi doménou v e-mailové adrese odesílatele a doménou použitou v EHLO (nepřímo tedy i s IP adresou odesílajícího serveru). S tím samozřejmě narazíme v takových případech, kdy lidé běžně odesílají maily např. ze své školní adresy přes SMTP svého poskytovatele, kde se domény samozřejmě neshodují. Řešením by bylo, udělat tuto kontrolu volitelnou – ze strany majitele domény – to by se opět dalo řešit přes DNS – pokud by zde byl určitý záznam, přijímající server by měl (nebo musel) odmítnout zprávy z jiných než (v DNS) vyjmenovaných IP adres.
    Pak by např. banky nebo ministerstva mohly říct, že zprávy s jejich doménou v e-mailové adrese se smí posílat pouze z vyjmenovaných IP adres (jejich brány) a jiné organizace by zase tuhle kontrolu nemusely vynucovat a umožnili by svým uživatelům posílat e-maily s danou doménou v adrese i z jiných SMTP serverů (poskytovatele, doma, na cestách).
Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
1.5.2009 11:54 Filip Jirsák | skóre: 67 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Kontrola IP adres a DNS
Což ale nebrání tomu, aby odesílací server (brána) měl také MX záznam, ale s tak nízkou prioritou, že na něj nikdy nedojde řada (a kdyby přece jen došla, mail může odmítnout a pak se za chvíli zkusí zase servery s vyšší prioritou).
Ten váš „odesílací server“ může být klidně Thunderbird nebo jiný klient schovaný za několikanásobným NATem. A může být v síti nějakého „WiFi ISP“, a vy z něj přitom budete posílat e-mail jako zaměstnanec nějaké mezinárodní společnosti s její doménou v adrese odesílatele.
Není to systémově moc hezké řešení → takže by bylo dobré přidat typ DNS záznamu, který by říkal, že daná IP je oprávněna použít toto doménové jméno v HELO/EHLO
Můžete popostoupit ještě o krok dál a uvědomit si, že nějaká doména uváděná v HELO/EHLO je úplně k ničemu, že důležitá je adresa odesílatele. Takže spojte doménu odesílatele, IP adresu odesílatele a kontrolu proti odpovídajícímu speciálnímu záznamu v DNS – a právě jste vymyslel SPF, i se všemi jeho neduhy.
Pak by např. banky nebo ministerstva mohly říct, že zprávy s jejich doménou v e-mailové adrese se smí posílat pouze z vyjmenovaných IP adres (jejich brány)
No vida, tak jste SPF nakonec vymyslel…
S tím samozřejmě narazíme v takových případech, kdy lidé běžně odesílají maily např. ze své školní adresy přes SMTP svého poskytovatele, kde se domény samozřejmě neshodují.
…a zároveň popsal i jeden z vážných problémů SPF. Takže je čas podívat se na nějaké rozumnější řešení, např. DomainKeys Identified Mail.
xkucf03 avatar 1.5.2009 12:19 xkucf03 | skóre: 49 | blog: xkucf03
Rozbalit Rozbalit vše Re: Kontrola IP adres a DNS
Ten váš „odesílací server“ může být klidně Thunderbird nebo jiný klient schovaný za několikanásobným NATem.

V takových případech se ale používá autentizované SMTP – povolit odesílání pošty komukoli (otevřená brána) bez ověření jména a hesla je sebevražda. SMTP serveru svého poskytovatele se tedy prokáži jménem a heslem a mail pak odchází ze serverů poskytovatele, které samozřejmě správné DNS záznamy mít budou.

A může být v síti nějakého „WiFi ISP“, a vy z něj přitom budete posílat e-mail jako zaměstnanec nějaké mezinárodní společnosti s její doménou v adrese odesílatele.

Pokud firma bude chtít povolit zaměstnancům posílat firemní maily i mimo firmu, zřídí jim (heslem chráněný) přístup k firemnímu SMTP serveru.

Takže je čas podívat se na nějaké rozumnější řešení, např. DomainKeys Identified Mail.

jj, DKIM vypadá zajímavě :-)

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
1.5.2009 13:25 Filip Jirsák | skóre: 67 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Kontrola IP adres a DNS
V takových případech se ale používá autentizované SMTP – povolit odesílání pošty komukoli (otevřená brána) bez ověření jména a hesla je sebevražda. SMTP serveru svého poskytovatele se tedy prokáži jménem a heslem a mail pak odchází ze serverů poskytovatele, které samozřejmě správné DNS záznamy mít budou.
Vy můžete ze svého klienta poslat e-mail rovnou cílovému serveru. To, že většina klientů je „hloupých“ a raději předají e-mail nějakému chytřejšímu serveru, který jej zase v roli klienta doručí na cílový server, neznamená, že to tak musí být vždy.
xkucf03 avatar 1.5.2009 14:08 xkucf03 | skóre: 49 | blog: xkucf03
Rozbalit Rozbalit vše Re: Kontrola IP adres a DNS

Tohle je věc dohody – podle mě by nebyla vůbec špatná konvence, že e-maily smí odesílat jen klient s příslušnými DNS záznamy. Výrazně by to omezilo problém botnetů odesílajících spamy. Cenou za to by bylo že bych si musel nastavit DNS záznam pro svůj notebook (když posílám přes svůj* postfix), což by nebyl problém, protože mám veřejnou IPv6 adresu, nebo bych použil SMTP server – buď svůj, nebo školní, nebo poskytovatele…Pořád mi to přijde jako přijatelná daň za ten boj proti spamu.

Pak jsou samozřejmě možné výjimky, kdy si např. ve své organizaci nastavím pravidla, že je možné posílat maily z jednoho stroje na druhý bez jakýchkoli omezení – je to moje síť, tak si tam ta pravidla určím já. Ale obecně na veřejném internetu by lepší mít striktnější pravidla. Chtělo by to ochranu proti spamu, která zprávu buď odmítne (vrátí) nebo doručí, ne jako teď, kdy se některé zprávy mohou ztratit, aniž by se o tom příjemce nebo odesílatel dozvěděl.

*) což je podobné, jako když někdo posílá mail rovnou z klienta na cílový server.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
1.5.2009 14:18 Filip Jirsák | skóre: 67 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Kontrola IP adres a DNS
Tohle je věc dohody – podle mě by nebyla vůbec špatná konvence, že e-maily smí odesílat jen klient s příslušnými DNS záznamy. Výrazně by to omezilo problém botnetů odesílajících spamy. Cenou za to by bylo že bych si musel nastavit DNS záznam pro svůj notebook (když posílám přes svůj* postfix), což by nebyl problém, protože mám veřejnou IPv6 adresu, nebo bych použil SMTP server – buď svůj, nebo školní, nebo poskytovatele…Pořád mi to přijde jako přijatelná daň za ten boj proti spamu.
To už by ale bylo něco zcela jiného, než je SMTP. Protože SMTP je založené právě na tom, že e-mail můžu odeslat odkudkoli a e-mail se bude doručovat co nejkratší možnou cestou k cíli. Protokol je možné samozřejmě změnit, ale v tom případě už by bylo lepší navrhnout pořádný nový protokol reflektující, kam se internet vyvinul, a ne jen do původního SMTP připlácnout nějakou další nelogickou změnu.
ne jako teď, kdy se některé zprávy mohou ztratit, aniž by se o tom příjemce nebo odesílatel dozvěděl.
Takové chování je v rozporu s RFC. Ale na rozdíl od mnoha jiných porušení RFC je tohle logické, protože pokud si server nemůže být jist, že odesílatel je pravý, je vysoká pravděpodobnost, že odesláním chybového e-mailu pošle ve skutečnosti spam. Logické by bylo třeba posílat chybové zprávy jako odpověď na e-maily, jejichž odesílatele se podařilo ověřit přes SPF nebo DKIM, ale to znamená zásah do organizace fronty zpráv v současných e-mailových systémech, takže to není tak jednoduché.

Navíc ale příslušné RFC požaduje, aby se všechny články po cestě maximálně snažily e-mail doručit a pokud to není možné informovali o nedoručení odesílatele, na druhou stranu e-mail nikdy nebyl koncipován jako služba se zaručeným doručením nebo zprávou o nedoručení, takže by na spolehlivost e-mailu neměl nikdo spoléhat.
xkucf03 avatar 1.5.2009 14:51 xkucf03 | skóre: 49 | blog: xkucf03
Rozbalit Rozbalit vše Re: Kontrola IP adres a DNS
na druhou stranu e-mail nikdy nebyl koncipován jako služba se zaručeným doručením nebo zprávou o nedoručení, takže by na spolehlivost e-mailu neměl nikdo spoléhat.

Ale vysvětluj to uživatelům, že se jejich e-mail zpozdil nebo nedejbože ztratil. Uživatelé si zvykli, že e-maily chodí spolehlivě a téměř okamžitě a jakoukoli odchylku od tohoto stavu berou jako chybu (přestože může být v souladu s původní zamýšlenou povahou SMTP). Takže by to chtělo buď nový protokol nebo přehodnotit pohled na SMTP.

Tím nezahazováním myslím hlavně to, že bychom měli maximum kontrol udělat během SMTP relace, kdy přijímáme mail od klienta nebo potencionálního spamera – v tu chvíli ho jde totiž bezpečně vrátit tomu, kdo ho posílá (ne někomu, kdo je jen uveden v hlavičce jako odesílatel). Ale když už ho přijmeme, tak ho doručit i přes podezření, že je to spam. Jasně, je tu problém, pokud jde mail přes více serverů, ale to už je pak problém těch serverů před námi, že např. mají špatně nastavené DNS.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
17.5.2009 11:23 Birkof
Rozbalit Rozbalit vše Re: Kontrola IP adres a DNS

Ja to uzivatelum vysvetluji tak, ze to prirovnam k pozemni poste, kde take neni zaruceno ze se dopis doruci a take je o tom nikdo neinformuje. Nakonec SMTP protokol byl odvozen od pozemni posty a podobne jako dopis je mozne poslat s dorucenkou, jde to i s e-mailem.

xkucf03 avatar 5.5.2009 19:07 xkucf03 | skóre: 49 | blog: xkucf03
Rozbalit Rozbalit vše DKIM Author Domain Signing Practices
…a zároveň popsal i jeden z vážných problémů SPF. Takže je čas podívat se na nějaké rozumnější řešení, např. DomainKeys Identified Mail.

Tak jsem se na to trochu kouknul a alternativou k SPF je DKIM Author Domain Signing Practices – ten umožňuje ostatním říct, že maily z mojí domény musí být podepsané, což je jako kdybych řekl, že maily z mojí domény musí pocházet z vybraných adres. Každé má svoje – DKIM mi přijde pružnější (jednou nastavím DNS a pak si jen nahrávám klíče na potřebné servery) a u SPF je zase mnohem jednodušší zkontrolovat, z jaké IP adresy mail přichází (než ověřovat elektronický podpis).

Osobně se mi ale dost líbí přístup, kdy majitel domény definuje pravidla, odkud* mohou být maily z jeho domény posílány – a pak je na něm, aby svým uživatelům poskytl např. vhodný SMTP server nebo webmail.

*) ať už IP adresy nebo podpisy.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes

Založit nové vláknoNahoru

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