Názory k článku SPF: proti spamu i přeposílání pošty
-
karel (neregistrovaný)
Dekuji za pekny clanek,
ale v mem pripade prisel s krizkem po funuse, problemem spf a odmitani posty jsem se musel zabyvat pred par mesici, kdy mi zpivali nekteri zakaznici ze se jim nedorucuji emaily.
V ukazce je pekne pouziti rozsahu z ipv4, zde jsem take narazil, nastavil sem politiku ze odesilat smi jen MX servery. Ovsem uz mi nedoslo ze nektere z domen nemaji AAAA zaznam. A ve chvily kdy postfix pouzil ipv6 jsme meli zas problemy.
No bylo to par probdelych noci nad logem kdo nas vse odmita a proc. -
Ja mam nasazeno SPF a preposilani resim stylem ze prichozi posta pada do tajneho .maildir ze ktereho se vlastnim demonem odesle pod hlavickou naseho serveru, az pak se presouva do uzivatelsky dostupneho .maildir (pres imap). Princip je - kdo preposila, bere za to odpovednost. Chce to ale mit spamfiltr na prijmu, aby jste nebyli oznacen za spammera, nebo aby vsichni pouzivali povinne SPF.
SRS me neprislo pouzitelny ani srozumitelny.
-
Ondřej CaletkaZlatý podporovatelJakou adresu tedy dáváte do hlavičky přeposílaných zpráv? Jak máte zajištěno, aby se případné zprávy o průběhu doručování přeposlaly původnímu odesílateli?
-
Vraci se to me jako adminovi. A tech par pripadu rocne dokazi vyresit rucne - treba reknu klientovi, at se obraci na danou osobu primo (nejcasteji se jedna o forward na seznam.cz). Holt kdyz se chce nekdo maskovat, ma to delat poradne, ne skrze lamerskeho ISP s cilem do webmailu. Kdyby se jednalo o castejsi ukaz odmitani forwardu od urciteho ISP, domluvim se primo s nim, at zaridi ze jeho zakaznik ma maily do kultivovanejsiho sveta preposlany pod jeho hlavickou.
Nejvetsi problem je u jedne svetove kuryrni sluzby, kdyz zadam tracking tak musim napsat i od koho a oni se to pak tak snazi posilat mym jmenem... coz neprojde, takze nemuzu pouzivat mailove notifikace no...
-
Filip JirsákStříbrný podporovatelPrincip je - kdo preposila, bere za to odpovednost.
Tak je to podle mne správně. Bohužel se za celou dobu používání e-mailu tak nějak ustálilo, že se při přeposílání obálkový odesílatel zkopíruje (což je podle mne špatně, mimo jiné i proto, že chyba může vzniknout až při přeposílání, a co s tím pak má odesílatel dělat).Třeba i Google doporučuje, aby se při přeposílání e-mailů na GMail kopíroval původní obálkový odesílatel s tím, že doména odesílatele může být použita při klasifikaci spamu (nebo-li pokud přepošlete spam pod svým jménem, připočte se spam skóre k vašemu jménu a ne původnímu odesílateli). Což pak znamená mít spamfiltr i před tím přeposílačem, jak píšete, což poněkud nabourává smysl toho přeposílání (přeposílám to i proto, abych antispamovou kontrolu a složku se spamem měl na jednom místě). Pro Google by snad mělo fungovat to, že na něj rozpoznaný spam můžete přeposlat, pokud do předmětu doplníte slovo „spam“ (což zase není moc šťastné řešení, raději bych to viděl v hlavičkách).
-
Ondřej CaletkaZlatý podporovatel
Já myslím, že problém je ještě složitější. Mělo by se rozlišovat přeposílání:
a) kompletně všeho, například proto, že uživatel s e-mailem na vlastní doméně používá schránku na freemailu, který má lepší web rozhraní. Hostingová společnost mu k doméně zdarma nabízí přeposílač pošty, případně i „doménový koš“
b) přeposílání vybraných zpráv v rámci filtrování na straně serveru. Například e-maily od nagiosu přeposílat na Gmail, protože Gmail umí push notifikace.V případě b) je bezesporu správné obálkovou adresu MAIL FROM přepsat na majitele schránky. Když dojde k problému při přeposílání, nedoručenka dorazí do původní schránky, kde si jí uživatel dříve či později přečte.
V případě a) ale žádná schránka u hostingové společnosti neexistuje a tedy jediný, koho je možné kontaktovat při problémech s doručením, je původní odesílatel. V takovém případě tedy přepisování adresy MAIL FROM není žádoucí.
-
Filip JirsákStříbrný podporovatel
Já si myslím, že neexistuje univerzální pravidlo, komu je chybová zpráva určena. Proto by měla být doručena tomu, od koho jsem e-mail dostal (tedy tomu, kdo e-mail přeposlal) – to je jediné místo, kde se dá podle příčiny chyby rozhodnout, komu ta chybová zpráva patří. Asi většina chybových zpráv je určená adresátovi (např. plná schránka) nebo přeposílajícímu (chybná konfigurace).
Pro odesílatele je to zajímavé jen jako upozornění „váš e-mail nebyl doručen“. Ale odesílatel s tou chybou zpravidla ani nic udělat nemůže. Pokud je třeba cílová schránka plná, měl by být nějaký náhradní kontakt u správce toho přeposílajícího serveru, odesílatel to asi řešit nebude – často ani jiný kontakt nemá.
To, že v případě a) hostingová společnost neví, co s chybou dělat, je tak trochu její problém – není problém nastavení přesměrování podmínit tím, že uvedu záložní e-mail nebo telefon, na kterém chci být informován v případě problémů při přeposílání. Myslím, že tedy i v tom případě a) je přepisování žádoucí, akorát že si přeposílající zjednodušují život a hází ty chyby na jiné.
-
Ondřej CaletkaZlatý podporovatel
Dlouho jsem o vašem názoru přemýšlel a dospěl jsem k závěru, že v případě a) je žádoucí, aby původní odesílatel dostával zprávy o problémech s doručením, tedy aby jeho adresa zůstala na obálce. I když s tím nemůže nic udělat, je informován, že zpráva nebyla doručena, přestože v rámci celé jeho administrativní působnosti byla předána a převzata bez problému.
I kdyby hostingová společnost nakrásně měla záložní kontakt na uživatele a při problémech s přeposíláním ho informovala alternativní cestou, stejně by se uživatel nedozvěděl obsah předmětné zprávy, protože ten už by byl ztracený. Hostingová společnost by tak musela ještě držet stínovou schránku, kam by odkládala přeposlané e-maily pro případ selhání. Představa, že někdo bude budovat takhle složitý systém náhradou za obyčejnou tabulku virtálních aliasů je nerealistická.
-
Filip JirsákStříbrný podporovatel
Podle mne je v případě a) žádoucí především to, aby došlo k odstranění problému, proto by měl být informován především správce přeposílajícího serveru. Nic mu nebrání zprávu o nedoručení pak poslat i původnímu odesílateli.
Navíc při posílání chyby původnímu odesílateli se předpokládá, že je z cílového serveru dostupný (což nemusí být vždy pravda – odesílatel může být třeba v nějaké síti oddělené od internetu). Dále to předpokládá, že odesílatel bude vědět, o jaký e-mail se jedná. Což také není vždy pravda, typicky u hromadných e-mailů – když odesílatel pošle hromadný e-mail, mimo jiné i na adresu abc@example.com, z té je e-mail přeposlán na adresu xyz@example.org a odsud se vrátí zpráva, že e-mail nebylo možné doručit, je to odesílajícímu k ničemu, protože takovou adresu nemá v databázi a netuší, kdo si na ni nechává e-maily přeposílat. Takže to musí řešit tak, že vytváří unikátní e-maily, aby je poznal (např. použitím unikátního obálkového odesílatele) - což zase znemožňuje využít té vlastnosti SMTP, že se jeden e-mail doručí v rámci jedné relace několika adresátům na stejném serveru.
Souhlasím s tím, že pro přeposílající server je to jistá práce navíc, ale myslím si, že kopírováním obálkového odesílatele se přeposílající server pouze zbavuje své zodpovědnosti a přehrává řešení svých problémů na někoho, kdo je často nijak vyřešit nemůže.
Mimochodem, pokud nebyl odesílatel validován pomocí SPF, neměla by se na jeho adresu posílat zpráva o nedoručení, protože je velice pravděpodobné, že je ta adresa falešná.
-
Ondřej CaletkaZlatý podporovatel
Ještě mě napadla jedna věc, poněkud náročná na zdroje, avšak eliminující odpovědnost přeposílatele: Potvrdit přijetí zprávy určené k přeposlání až v momentě, kdy její přijetí potvrdí cílový server. Přeposílač by tak vlastně mohl být jen jednoduchá TCP proxy, která by pouze přepisovala obálkovou adresu adresáta. Problém s identifikací nedoručenky, to ale samozřejmě nevyřeší.
-
Filip JirsákStříbrný podporovatel
Pro antispamovou kontrolu se tenhle způsob používá běžně, ale to mám ten cílový server přeci jen pod kontrolou a vím, jak rychle bude odpovídat. Problém by taky byl, pokud by se e-mail pro jednu adresu přeposílal více adresátům (taková e-mailová konference pro chudé). Ale je to zajímavý nápad.
-
uranix (neregistrovaný)
https://github.com/andrenth/srsly
je potřeba použít release přímo od autora:
$ git clone https://github.com/andrenth/release/
$ cd release
$ git checkout -b 687173cf3
$ git reset --hard 687173cf3b184b5204278aab9d87c0bb0d7fa26e
$ ocaml setup.ml -configure
$ ocaml setup.ml -build
$ ocaml setup.ml -install -
j (neregistrovaný)
SPF nahozeno uz peknych par let, zaznamenany jednotky pripadu kdy se mail vratil s tim, ze je kvuli SPF nedorucitelny (pri preposilani). 99% z nich od seznamu.
Jak bylo zmineno, za fungujici forward je zodpovedny ten, kdo ho pouziva. Ostatne, cely system mailu je koncipovan presne stejne - kazdy si MTA muze nastavit jak chce.
-
j (neregistrovaný)
Jiste, ridice taky nezajimaj nejaky ty znacky kolem silnic, proc by si prave ted nemoh jet svych 200, ze ... sak je to BFU tak ho to nezajima.
Ve chvili kdy jde o penize se nepouziva mail. Pripadne se pouziva tak, aby jeho neduhy byly eliminovany. A ted sem muzes zacit psat pohadky na tema ze mi treba bude psat mailem novy uzasny zakaznik, ktery mi chce udelat kset za desitky mega a prave ten jeho mail mi nedorazi ... lol.
Milej zlatej, kdyz se spamem bude kazdej zamestnanec prehrabovat 1/2 hodiny denne (a to se bude prehrabovat dyl), tak to firmu pri 100 lidech stoji +- 300 000 kazdej mesic. TO jsou PENIZE, ktery majitele zajimaj. Nejakej mail kterej nedorazil nikoho nedojme. Mail totiz nemusi dorazit asi tak z miliardy duvodu a spf v tom hraje roli 0,000prd.
-
Jenda (neregistrovaný)
> Ve chvili kdy jde o penize se nepouziva mail.
Zákazníci mého klienta ho tak prostě používají a protože jsou to nadnárodní korporace, tak nějaký „Jenda správce serveru v pidifirmě“ to asi těžko změní.
> A ted sem muzes zacit psat pohadky na tema ze mi treba bude psat mailem novy uzasny zakaznik, ktery mi chce udelat kset za desitky mega a prave ten jeho mail mi nedorazi ... lol.
Nejsou to desítky mega, ale desítky litrů jo.
-
Martin Mareš (neregistrovaný)
Mám ze SPF velmi podobný pocit. Standard, který přináší spoustu problémů (rozbil veškeré forwardování pošty na světě a jeho autoři si naivně myslí, že se celý svět přizpůsobí) a vůbec nic neřeší. Spamu neubylo, ani se snáz nedetekuje. A pokud se někdo chce chránit před podvodnými maily odesílanými jeho jménem, může daleko účinněji použít PGP nebo S/MIME.
-
j (neregistrovaný)
Pise nekdo, kdo netusi o cem ... SPF resi, ze MTA mail VUBEC NEPRIJME, a tudiz ho nemusi ukladat na disk, nemusi na nem provadet zadne anti(spam/vir/...) kontroly.
To kdo ten mal poslal nikoho nezajima. Ale kazdyho zajima jak zredukovat miliony spamu ktery se zbytecne zpracovavaj.
-
JmJ (neregistrovaný)
To je vsechno alibismus.
To, ze mail neni garantovana sluzba neznamena, ze se na nej lide nespolehaji. Muzeme o tom debatovat, muzeme se o to prit, ale to je tak vsechno, co s tim muzememe delat.
A ja rozhodne radeji budu filtrovat spam treba v TB s tim, ze budu mit dostupne vsechny maily, nez o nejake maily prijit.
Preposilani mailu funguje snad 30 let a nevidim duvod, proc by nekdo mel vymyslet system, ktery nas ochrani pred spamem, ale zaroven de facto zrusi 30 let zavedenou vec.
Sice sme vas ochranili pred 100 spamu denne, ale ty 3 emaily, ktere vam poslali z jinych firem ohledne novych zakazek vam nedosli, protoze SPF. Toto mi rict ITak, tak s nim vyrazim zavrene dvere.
-
M. (neregistrovaný)
Ano, SPF používáme jako součást DMARC spolu s DKIM. V odchozím směru politika s koncovým ~all u SPF. Tahle kombinace u těch, co to používají, funguje víc než dobře. Pokud dojde k forwardu mailu, tak nesouhlasí SPF, ale sedí to DKIM. Situací, kde se forwardem rozbije i DKIM je hodně málo.
V přichozím směru se uplatňováno taktéž DMARC, pokud odesílající má i SPF, tak při souhlasu se pouští rovnou (ignorují se věci jako +all), pokud SPF nesedí nebo není, je uplatněn greylisting.
Jen samotné a holé SPF bych asi už nedával (bez kombinace s DKIM/DMARC). -
vokac (neregistrovaný)
Zasadni problem SPF je v tom, ze pro korektni fungovani preposilani mailu tento standard vyzaduje nasazeni SRS na _vsech_ mailserverech, ktere nekdy forwarduji email (bez ohledu na to jestli oni sami SPF pouzivaji). Priblizne zacatkem roku 2011 jsem detekoval vcelu nestastne nastaveni seznam.cz, ktery zacal odmitat forwardovane maily s "fail" politikou odesilatele a vzhledem k tomu, ze v te dobe nebylo nic po ruce tak jsem si napsal vlastni https://github.com/vokac/srs-milter.
Ruzne mailservery provadi forward mailu ruzne - nektere prepisuji mail envelope, kde jako odesilatele uvedou lokalni adresu uzivatele pro nejz je mail preposilan (treba Exchange pri existenci schranky a uzivatelske konfiguraci preposilacich pravidel) a v takovem pripade SPF nezpusobuje problemy (na druhou stranu se to takhle nebude uplne korektne chovat v pripade "mail delivery failure" na cilovem serveru). Pri klasickem forwardu se mail envelope neprepisuje (napr. pri pouziti Exchange a mailoveho uctu bez schranky s forwardem pres "targetAddress" v AD) a v takovem pripade je potreba zprovoznit SRS.
Jinak sveho casu jsem cetl, ze napr. gmail neprijimal maily prichazejici z IPv6 adres, jejichz odesilatel nepouzival bud SPF nebo DKIM, takze asi neni na skodu zauvazovat nad nasazenim jedne z techto technologii (osobne se mi o trosku vic zamlouva DKIM, i kdyz jeho pouziti take nemusi byt uplne bez vedlejsich efektu).
-
bmann (neregistrovaný)
Osobne SPF nepouzivam, prijde mi jako spatna volba, viz. rozbiji preposilani a pridava praci jinde.
Pouzivam DKIM, ktery nerobiji preposilani.
Nekteri v diskuzi zminovali ze pouzivaji SPF + DKIM. Rad bych vedel proc. Muze te mi nekdo objasnit proc chtit pouzit SPF kdyz mam funckni DKIM (a pripadne i DMARC record)?
-
Ondřej CaletkaZlatý podporovatel
Třeba proto, že SPF a DKIM jsou dva stavební kameny, na kterých stojí DMARC?
Jinak DKIM sice nerozbíjí přeposílání, ale zase celkem dobře rozbíjí e-mailové konference :)
-
bmann (neregistrovaný)
Na problem s konferencema jsem nenarazil, dobre vedet.
Jestli si pamatuji dobre tak v DMARC neni vyslovene volba, ktera by specifikovala, ze pouzivam jenom DKIM a nejak jsem si z toho vzal ze to pocita s obema. Ale ze defaultne pokud nepozivam SPF tak to nereportuje a hlasi jen problem u DKIM - a tak jsem SPF nepouzil ponevadz mi DKIM prijde dostatecny.
Ale moc jsem se v tom nestoural :-)Diky vsem za info ...
-
M. (neregistrovaný)
Problém s DKIM a konferencema je, pokud konferenční server dělá nějaké změny v mailu, což obvykle dělá. Takže jakmile tam narve do mailu třeba patičku, že mail je z "konference X s archívem na adrese Y", tak přestane souhlasit hash těla zprávy a pak je na koncovém příjemci, jak se s tím popere (stejný problém dělá konference i v případě, že mail je poslán s S/MIME digitálním podpisem). Pokud konfereční server dělá jen prostý mail aliasing, nemění subjekt/tělo, maximálně si přidá nějaké X-...: hlavičky, tak se DKIM nerozbije.
DMARC postupuje při ověřování (RFC7489):
"Receivers compare the RFC5322.From address in the mail to the SPF and DKIM results, if present, and the DMARC policy in DNS."
Takže se snaží použít oboje, pokud jedno není, označí si ho jako none a vyhodnocuje jen na základě toho druhého... -
Santiago (neregistrovaný)
> Jinak DKIM sice nerozbíjí přeposílání, ale zase celkem dobře rozbíjí e-mailové konference :)
Do dela zhruba v trech pripadech:
1) Konference pridava paticku do tela mailu
2) Konferencni adresa se vklada do Reply-to hlavicky
3) Konference pridava svuj tag do Subject hlavicky
Prvni pripad je hloupost, ktera mela uz davno vymizet. Narusuje i jine metody digitalniho podpisu, proto konferencni software je na to cast pripraven a v takovem pripade paticku nevklada.
Druhy pripad je rozporuplna zalezitost, ktera mela mnoho oponentu jiz dlouho pred DKIM, i kdyz pragmaticky prepisovani Reply-to casto smysl dava, zejmena pro soukrome konference.
Treti pripad je drobnost, ktera se da nahradit List-* hlavickama. Ackoliv osobne preferuju filtrovani podle tagu (nebot se tak do slozky s konferenci dostanou i soukrome odpovedi na mail z konference), tesknit po nich nebudu.
Takze celkem vzato DKIM sice muze rozbit e-mailove konference, ale neni problem je nastavit tak, aby s DKIM fungovaly korektne. Oproti tomu SPF je broken by design.
DKIM ma i sekundardni pozitivni dopad - v zasade je to digitalni razitko treti strany, ze obdrzela a preposlala e-mail od nekoho, koho typicky autorizovala. Zajistuje tedy urcitou miru duveryhodnosti a nepopiratelnosti u e-mailu, a to v mire rozsireni, ktere klasicky digitalni podpis e-mailu za 20 let zdaleka nedosahl.
-
Filip JirsákStříbrný podporovatel
SPF rozbíjí pouze rozbité přesměrování. A teoreticky není problém nastavit přeposílání tak, aby se SPF fungovalo korektně (u praktického nastavení může být problém v konkrétních implementacích, úplně stejně jako u těch konferencí). Třeba právě ty e-mailové konference do obálkového odesílatele nekopírují původního odesílatele, ale dávají tam svůj e-mail - autoři už asi za ta léta zjistili, že dělat to jinak je špatně.
Ta "drobnost" v podobě úprav předmětu je dost podstatná věc. Oni e-mail občas používají i lidé, kteří o nějakých hlavičkách vůbec netuší, vůbec nepoužívají nějaké filtrování nebo štítky - jenom chtějí u e-mailu na první pohled vidět, že jim přišel přes konferenci.
-
M. (neregistrovaný)
Protože DMARC je zamýšlen jako kombinace SPF a DKIM. Zkrátka ideálně má souhlasit oboje při kontrole, ale stačí když souhlasí jen jedno.
Jinak, že se DKIM při přeposílání nerozbíjí, tak to není úplně pravda. Dle pozorování a sttistik, co vrací DMARC, tak někteří přeposílači DKIM dokáží rozbít také. :-(Samotné DKIM nic neříká o tom, zda je to OK, maximálně při použití ADSP záznamu mohu říci, že veškerá pošta měla by/musí být podepsána. Bohužel je ADSP využíváno zcela minimálně.
DMARC má smysl v tom, že ho dneska aplikuje řada velkých mailových hráčů (Gmail, Yahoo, Hotmail, ....), kteří jsou i jeho autorem. Další plus u DMARC je, že si můžu publikvoat záznam říkající, že přijímající servery mi mají posílat statisityky o tom, jak si vedou maily z mé domény - takže dostane přehled, kolik mauiů k nim došlo, odkud došly, zda souhlasily SPF a DKIM a jak s nima cílový server naložil.
-
Filip JirsákStříbrný podporovatel
Nekteri v diskuzi zminovali ze pouzivaji SPF + DKIM. Rad bych vedel proc. Muze te mi nekdo objasnit proc chtit pouzit SPF kdyz mam funckni DKIM (a pripadne i DMARC record)?
Jak se dá s DKIM+DMARC nastavit, že e-mail sFrom: user@example.comje věrohodný, pokud má v DKIM podpisu uvedenod=gmail.com? V SPF se to pro obálkového odesílateleMAIL FROM user@example.comnastaví snadno, do SPF záznamu proexample.comse dá reference na SPF progmail.com. -
M, (neregistrovaný)
V případě Google Apps na vlastní doméně to je na pár kliknutí v managementu, kdy vygeneruje DKIM klíče specifické pro danou doménu a bude s něma korektně podpisovat jako d=example.com místo d=google.com.
Ale pokud je otázka obecná, jak pověřit jinou doménu jako věrohodného podepisovatele na úrovni ADSP, tak ano, jde to. Jmenuje se to ATPS rozšíření pro DKIM. Stačí do domény example.com doplnit:
_adsp._domainkey.example.com IN TXT "dkim=all; atps=ys; asl=google.com;"
XLVJKS4VOMOGRLTOIW6R4JJOWRLAZXCF._atps.example.com IN TXT "v=atps01; d=google.com;"
a bude to znamenat, že za example.com se autoritativně podepisuje google.com.
Nicméně Authorized Third-Party Signatures (ATPS) jRFC6541 je stále ve stavu experimental, takže se na to nedá plně spoléhat, že to všechny DKIM validátory budou umět (řada to podporuje). -
Filip JirsákStříbrný podporovatel
Díky, byl to obecný dotaz (i když mne zajímá hlavně ten free GMail). A jde to delegovat i na víc klíčů? Tedy že e-maily pro doménu example.com může podepisovat buď klíč gmail.com nebo example.com? (Většinu e-mailů odesílám z GMailu, což řeší váš příklad, ale některé mohu odesílat přímo ze svého serveru. Pro sebe to samozřejmě mohu řešit odesíláním z mého serveru přes GMail, ale od jiných uživatelů nemůžu chtít přihlašovací údaje ke GMailu.)
-
M. (neregistrovaný)
Ano, můžu definovat větší počet domén, které mohou podepisovat za example.com.
Uvedený příklad automaticky znamená, že můlže podepisovat example.com sám sebe a/nebo to může podepisovat i google.com (případně idalší definovaný jako _atps DNS záznam).
U toho ADSP záznamu se jen patřičně rozšíří to asl=google.com,x.cz,y,cz. a patřičně přidají i ty jednotlivé _atps DNS záznamy pro každou doménu.
Dále, pokud se používá i DMARC, tak v DMARC DNS záznamu se také definuje, že pro DKIM připouští ty ATPS záznamy pomocí volby "atps=y" a můžu i vyjmenovat zde, které domén se připouští pomocí "asl=google.com,x.cz,y,cz". V doméně example.com musí samozřejmě existovat i ty jednotlivé _atsp DNS záznamy.
Zde je pěkný online generátor ADSP i DMARC záznamu s podporou pro to ATPS:
http://www.winserver.com/public/wcadsp/default.wct
http://winserver.com/public/wcdmarc/default.wct -
SPF máme na doméně scio.cz už roky (~, ale taky jsem si na to musel přijít sám :). DKIM, ADSP a DMARC asi dva roky. Stejně tak TLS oběma směry. Žádné problémy.
Při příjmu mailů kontrolujeme SPF, DKIM, ADSP. Čas od času majitele nějaké domény upozorním, že odesílá v rozporu s SPF (nejde o přesměrování), ale většinou to nemá žádný efekt :)
-
Jo a ještě použitý SW: http://www.dataenter.com/products/xwall.htm
Geniální antispam pro Windows platformu.SPF nám dost pomohlo proti mailům, kdy se někdo snažil nás spamovat (jako) z našich vlastních domén.
-
Přeposílání není jediný problém ... problém je i to, že každý by měl používat SMTP poskytovatele, kam je připojený. Ať už z důvodu, že dotyčný jiné blokuje, nebo naopak SMTP poskytovatele schránky neumožňuje relay.
Svého času to dělalo @iol.cz Nasadilo tvrdé SPF a zároveň nedovolilo připojení odjinud, než ze sítě telecomu. Co měl takový uživatel dělat? Použil SMTP ze své sítě. Fungovalo to. Dokud nepřišel SPF.
Z mého pohledu každé řešení sice něco vyřeší, ale nějaký problém zase přidá.
-
ebik (neregistrovaný)
"každý by měl používat SMTP poskytovatele, kam je připojený"
To je podle mne mýtus. Freemail mne "ověřil". Odesílám emaily z jeho webového rozhraní a navíc mi poskytuje API (standardizované: SMTP + IMAP), do kterého se _přihlásím_ a on to pak odešle prakticky stejně jako z toho webového rozhraní. Já happy user, neboť mejl z mého MUC je (ne)zahozen stejně (konzistentně) s tím, jako bych ho posílal z webového rozhraní. V ideálním světě pak freemail aplikuje "stejný" antispam na ověřeném SMTP jako na svém webovém rozhraní. Další výhodou je, že odmítnutý email se má prakticky vždy kam vrátit, pokud odesílající SMTP server spravuje ten samý subjekt, jako mojí schránku. (Navíc lze aplikovat back-scatter filtering.)
V mém případě to došlo tak daleko, že sice nepoužívám freemail, ale máme s kamarády server, takže si ze svého NB SMTP spojení z MUC tuneluju pomocí ssh (ověřování SSH věřím výrazně víc (umím líp nastavit), než ověřování SMTP) na SMTP server.
-
Ondřej CaletkaZlatý podporovatelPřesně tak, používání SMTP serveru lokálního internetového poskytovatele je obecně vnímáno jako špatná praktika. Sice vypadá efektivně z hlediska topologie, zbývají už ale samé nevýhody:
- Od internetového poskytovatele chci síťově neutrální konektivitu, nikoli, aby pro mě provozoval nějaké síťové služby.
- Nemůžu ovlivnit, kdo bude co všechno posílat tímto serverem a na kolika blacklistech se kvůli tomu server ISP ocitne.
- Pokud budu mít pochybnosti o průběhu doručení zprávy, nemám jak to ověřit. Pravda, tuhle možnost nemám ani u freemailů, ale u firemních schránek obvykle ano.
- Může dojít k porušení pravidel SPF a DKIM.
- Nemám důvod svému ISP, při tom všem, co o mě už ví na základě metadat komunikace, ještě přidávat „k nahlédnutí“ kompletní obsah e-mailové komunikace.
-
Ondřej CaletkaZlatý podporovatel
K tomu, abych mohl šifrovat end-to-end je bohužel potřeba i na druhé straně. A bohužel, takováto podpora i na straně takových institucí jako jsou banky nebo úřady.
Je vlastně nějaká relevantní výhoda v používání smart relay internetového poskytovatele? Já jsem na žádnou nepřišel.
-
Ondřej CaletkaZlatý podporovatel
Oprava prvního odstavce:
K tomu, abych mohl šifrovat end-to-end je bohužel potřeba podpora i na druhé straně. A bohužel, takováto podpora není obvyklá ani u takových institucí jako jsou banky nebo úřady.
-
Já (neregistrovaný)
Používám kratší dobu SPF(~all), DKIM i DMARC(obojí relaxed). Ale je fakt, že o to víc sleduju delivery reporty, nicméně zatím bez nějakých problémů. Používám poste.io
ČLÁNKY DO MAILU