Vlákno názorů k článku Stavíme vlastní e-mailový server: Apache, DANE, Bind a Postfix od Josef Pavlik - nemate nekdo ideu proc ten zk...ny google hazi...
-
nemate nekdo ideu proc ten zk...ny google hazi vetsinu mych mailu do spamu?
Sam sobe si poslu mail, uz jsem kvuli nim nastavil sfp, dkim a dmark. Reverse dns mi funguje, ale stejne kdyz neco poslu nekomu, kdo ma ucet u googlu, tak mu to hodi do spamu.
Tohle je report (show original) mailu jak prisel na gmail a skoncil ve spamu:Created at: Tue, Jun 13, 2017 at 6:28 PM (Delivered after 126 seconds)
From: EURO3G DemoEuro3G <noreply@e3g.spintec.com>
To: xxx_zmeneno_xxx@gmail.com
Subject: EURO3G DB BACKUP - 2017-06-13 18:28:19
SPF: PASS with IP 188.68.37.226 Learn more
DKIM: PASS with domain e3g.spintec.com Learn more
DMARC: PASS Learn moreKrome toho jakykoliv mail co poslu na google se zpozdi o 2 minuty (vicemene presne). To taky asi delaji schvalne. Pokud tam poslu mail z jineho google uctu, dorazi okamzite. Potiz je v tom, ze mam system, ktery ma v realnem case odpovedet na dotaz zakaznika. Kdo ma ucet u googlu mi stihne mezitim 2 krat zavolat, ze mu nic neprislo.
Ja uz si s tim proste nevim rady...
-
j (neregistrovaný)
Tohle ber jako krsitalovou kouli ...
Kolik tak tech mailu na guugl dorucujes? Mineno celkem vsem? Neoznacil te nahodou nekdo z nich za spamera? Predpokladam ze to bude nejakej unifikovanej mail ... tudiz vsem vicemene stejnej.
BTW: Ocekavat od mailu zcela libovolnou odezvu je naprostej nesmysl. Ten mail proste nemusi dorazit vubec nikdy a ty to nemuzes ovlivnit. Pokud bys hypoteticky chtel, tak to lze leda v situaci, kdyz mas pod kontrolou jak odesialjici tak prijimajici MTA (takhle defakto fungujde de-mail).
BTW2: Jinak mam pocit, ze sem onehda nekde cet cosi na tema ze guugl pri dorucovani penalizuje ty, ktery posilaj prave takovyhle automaticky maily a i kdyz je nevyhodnoti jako spam, tak je dorucuje proste az na ne dojde.
-
> Kolik tak tech mailu na guugl dorucujes?
Netusim. Kdo z nasich zakazniku ma gmail a kdo si nastavi po kolika minutach se mu ma posilat backup, to nevim a nemuzu ovlivnit. ovsem nejde jenom o tyto backupy, mail server samozrejme zajistuje nekolik dalsich sluzeb krome standardniho mailu.> Ocekavat od mailu zcela libovolnou odezvu je naprostej nesmysl
Ne tak uplne. Pokud je konecny prijemce dostupny (v pripade gmail, seznam a podobnych podvodniku je to 99.9% casu), tak mail nema duvod byt zdrzovany. Jenom v pripade nedostupnosti nebo umeleho zvyhodonovani 'spratelenych odesilatelu' muze dojit ke zdrzeni.> Jinak mam pocit, ze sem onehda nekde cet cosi na tema ze guugl pri dorucovani penalizuje ty, ktery posilaj prave takovyhle automaticky maily
Jaky by meli zajem umele zdrzovat maily? Jedine aby donutili lidi prejit na gmail. Coz je teda svinarna, omluvte me za ten vyraz. Protoze kdyz budu mit ucet u guuuglu a maily od lidi z guuglu mi budou chodit v realnem case, kdezto od lidi zvenku budou chodit kdovi kdy, tak je presvedcim at prejdou ke guuglu, ze to bude rychlejsi.
Zrovna dnes jsem naprosto vazne prohlasil "zlatej Microsoft", kdyz jsem se sral s problemama s googlem. Zacinam ho ze srdce nenavidet. A to jsem mu kdysi fandil. Zatim nasim zakaznikum doporucuju zaridit si nekde solidni mail. -
j (neregistrovaný)
1) Mas snad logy ne? Nejakej grep a obratem vis kolik toho slo na guugla.
2) Praveze tak uplne, ty snad neresis ze ti to nefunguje coz samo o sobe zcela jasne doklada ze to ani fungovat nemuze? Ty proste nemuzes ovlivnit jak s tvym mailem cilovej stroj nalozi. Muzes se o to snazit (spf a dalsi) ale ve finale to ovlivnit nemuzes.
3) Ma zajem dorucovat maily o ktery jeho ovecky stojej, a nema zajem dorucovat ty, o ktery nestojej. Ve tvym pripade pak s pravdepodobnosti 99% je situace takova, ze nejakej quickcheck vyhodnoti maily od tebe jako podezrely a hodi je do fronty "ke kontrole" kde holt ty 2 minuty (coz je samo naprosto smesny) cekaj, nez na ne prijde rada.
Sem zvedav, jak budes ty maily "obratem" dorucovat, az jim zas nebude fungovat nejaka routa.
Mimochodem, vazne to posilas z 188.68.37.226 ??? jestli jo, tak se vubec nedivim ze koncis ve spamu.
Unable to connect after 15 seconds.
-
jo, odesilam to za 188.68.37.226. Kde je problem? Jestli jsem to dobre pochopil, snazil ses na to spojit na 25. Neakceptuju spojeni od cizich, tohle je server ktery neprijima postu. To dela jinej. Tenhle akceptuje spojeni na 25 jenom z vnitrni (vpn) site.
Myslis, ze google se snazi spojit zpatky a na zaklade toho dela zaporne body?
On by teda samozrejme nebyl problem akceptovat spojeni a pak jenom zahazovat co po nem prijde od cizich. -
Sten (neregistrovaný)
Pokud je konecny prijemce dostupny (v pripade gmail, seznam a podobnych podvodniku je to 99.9% casu), tak mail nema duvod byt zdrzovany. Jenom v pripade nedostupnosti nebo umeleho zvyhodonovani 'spratelenych odesilatelu' muze dojit ke zdrzeni.
Nebo pokud provádějí hromadnou analýzu e-mailů posílaných vaším serverem, jelikož jim e-maily s krátkým textem a velkým archivem přijdou podezřelé.
-
Ano s tím už jsem se setkal taky. Například mail s textem "posílám kopie faktur" a v mailu jako příloha šest faktur v PDF a jedna jako oscanované JPG, tak tohle bylo vyhodnoceno někde cestou jako spam.
Ale to samé, když se ty PDFka a JPGéčko zazipovala do jednoho TGZ archívu, tak to prošlo v pohodě. -
Problem je v tom, ze pokud posilas nejaky dokument nebo file, tak je to naprosto normalni stav.
Dokonce je to (bohuzel) naprosto bezne i u vetsiny lidi, co ti poslou mail bez subjectu a bez body, jenom s megovou prilohou, je to DOC file a v nem 3 radky s textem, co ti vlastne chteji.
Takovy maily ovsem vetsinou zahazuju :-). -
Takze diky Tuxikovi se podarilo vyresit aspon ten problem s timeoutem.
Nakonec to byl timeout na nasi strane. Server se snazil spojit se s destination serverem (v tomto pripade xxx.google.com) po IPv6. Prestoze nas server nema public IPv6 adresu, sendmail udelal connect na gugli ipv6 a v tomto connectu visel 2 minuty nez prisel timeout. Je divne, ze neskoncil okamzite s errorem 'no route to host' nebo neco podobneho. Teprve potom to sendmail zkusil dorucit po ipv4, coz okamzite proslo, google to prevzal a hotovo.Reseni:
v sendmail.mc bylo potreba zakomentovat tyto dva radky:
#dnl DAEMON_OPTIONS(`Family=inet6, Name=MTA-v6, Port=smtp, Addr=::1')dnl
#dnl DAEMON_OPTIONS(`Family=inet6, Name=MSP-v6, Port=submission, M=Ea,Addr=::1')dnlProblem s oznacovanim mailu jako spam ovsem bohuzel zustava...
poznamka:
Nez me zacnete kamenovat za to, ze jsem problem vyresil zakazanim ipv6, tak vezte, ze jsem velky priznivec ipv6. Pouzivam ho, kde muzu. Dokonce jsem ho tento tyden pouzil i na Androidu. Pokud nekdo potrebujete poslat UDP broadcast na celou lokalni sit, tak vezte, ze staci poslat packet na adresu "ff02::1%wlan0" a dostanete ho na vsech zarizenich pripojenych na tuto lokalni sit.
Ovsem tady v pripade tohoto mail serveru jsme preferovali reseni ve forme "rychle to zaplacneme". Samozrejme v budoucnu dame do poradku ipv6, ale to samozrejme neni zalezitost zmeny dvou radku v configu. Snad se nam podari vyrazit z providera nativni ipv6, tim se vyresi spousta problemu. -
Mě ještě s tou IPv6 napadla jedna věc... zkusil bych se telnetnout na nějakou googlí IPv6 adresu na port 25 a zkusil bych se podívat tcpdumpem, co to dělá, případně zkusit traceroute, protože podle mě to ten server muselo opustit, ale někde se to pak muselo zaseknout. Kdyby vůbec neměl routu, určitě by tak dlouho nečekal...
-
Praveze jo, zkusil jsem udelat par pokusu. Kazdy normalni program skoncil okamzite na nejakem erroru, kdyz se pokusi spojit na ipv6 adresu. Ovsem sendmail na tom connectu visel dokud neprisel SIGALM a nekillnul to. Nesledoval jsem to uplne cele, protoze jsem se na to bindnul strace -p az kdyz bezel (a visel), takze nevim, jak presne probihal setup tohoto spojeni. V kazdem pripade to pak viselo na tom connectu.
V kazdem pripade jeste jednou dik za spolupraci.
ciao
Jet
ČLÁNKY DO MAILU