Forum » Pomoč in nasveti » Pošiljanje emaila na @siol.net
Pošiljanje emaila na @siol.net
ivanl ::
Pozdavljeni,
Zanima me, če ima še kdo težave s pošiljanjem emailov iz kakšnega resseler računa ali VPS mašine kjer imate nosilno domeno. SIOL je nameč uvedel pri prejemanju emailov SFP preverjanje in vse maile iz raznih resseler računov in VPS mašin zavrne oziroma jih ne dostavi, zavrnitveneg sporočila pa ne pošlje pošiljatelju nazaj, da email ni bil dostavljen.
Z njimi se že bockam 10 dni pa se obnašajo kot da so edini na tem svetu. Prosim preverite, če imate kakšen siol email ali kolega, ki ga ima oziroma stestirajte iz vaših vps mašin in resseler računov.
Kakšna rešitev bo seveda dobrodošla. Če imate težave pa veselo pošljite email na tehnicna.pomoc@telekom.si .
Stvar, ki so jo uvedli mislim, d aje malo nesmiselna.
LP Ivan
Zanima me, če ima še kdo težave s pošiljanjem emailov iz kakšnega resseler računa ali VPS mašine kjer imate nosilno domeno. SIOL je nameč uvedel pri prejemanju emailov SFP preverjanje in vse maile iz raznih resseler računov in VPS mašin zavrne oziroma jih ne dostavi, zavrnitveneg sporočila pa ne pošlje pošiljatelju nazaj, da email ni bil dostavljen.
Z njimi se že bockam 10 dni pa se obnašajo kot da so edini na tem svetu. Prosim preverite, če imate kakšen siol email ali kolega, ki ga ima oziroma stestirajte iz vaših vps mašin in resseler računov.
Kakšna rešitev bo seveda dobrodošla. Če imate težave pa veselo pošljite email na tehnicna.pomoc@telekom.si .
Stvar, ki so jo uvedli mislim, d aje malo nesmiselna.
LP Ivan
ivanl ::
Ne more bit, če imaš npr na gostovanju nosilno domeno blabla.com , maile pa pošiljaš iz kuku.si, ki gostuje na resseler računu blabla.com , se ti v headerju pokaže ime nosilne domene v mailu.
Zgodovina sprememb…
- spremenil: ivanl ()
pegasus ::
Torej ne znaš pravilno pošiljati maila in siol z vso pravico zavrne tvoj crap.
Pravice, da je tvoj mail dostavljen nimaš. Imaš pa dolžnost mail pravilno poslati.
Pravice, da je tvoj mail dostavljen nimaš. Imaš pa dolžnost mail pravilno poslati.
Zgodovina sprememb…
- spremenil: pegasus ()
ivanl ::
S SPF nastaviš, da lahko tudi blabla.com strežnik pošilja maile za kuku.si.
Poglej si headerje tega testnega emaila:
<strong>Received: from blabla.com (kuku.si. [193.243.154.28]</strong>) by mx.google.com with ESMTPS id 7si13478247wrj.46.2017.01.17.06.28.30 for <test@gmail.com> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Jan 2017 06:28:31 -0800 (PST) Received-SPF: pass (google.com: domain of test@kuku.si designates 193.243.154.28 as permitted sender) client-ip=193.243.154.28;
V headerju se pojavi domena blabla.com.
Zgodovina sprememb…
- spremenil: ivanl ()
Miha 333 ::
Header, ki ga gledaš, nima veze. Veze ima izključno domena naslova pošiljatelja za znakom @ in zapis SPF v DNS te domene. V bistvu je glede na
Težava mora biti drugje. Naj ti pošljejo izpis iz loga.
domain of test@kuku.si designates 193.243.154.28 as permitted senderSPF pravilno konfiguriran.
Težava mora biti drugje. Naj ti pošljejo izpis iz loga.
ivanl ::
Header, ki ga gledaš, nima veze. Veze ima izključno domena naslova pošiljatelja za znakom @ in zapis SPF v DNS te domene. V bistvu je glede nadomain of test@kuku.si designates 193.243.154.28 as permitted senderSPF pravilno konfiguriran.
Težava mora biti drugje. Naj ti pošljejo izpis iz loga.
To sem skopiral iz gmail emaila, ki brez težav pride, maili prihajajo tudi na vse druge domene razen seveda na @siol.net, ki jih izbriše oz. jih ne dostavi. Na siolu eden za drugega ne vedo, lahko jih vprašam za loge, ampak jih bom čakal pol leta.
Nisem edini, ki emaila ne dobi, težava je predvsem tujina. Če imaš poslovne partnerje v tujini se ti lahko večkrat zgodi, da emaila ne dobiš, pa niti ne veš, da so ti ga poslali, pošiljatelj pa ne ve da ga nisi dobil.
LP Ivan
pegasus ::
Če se kakorkoli zanašate na email, potem nase kličete težave, ker uporabljate napačno orodje.
pegasus ::
X.400 če hočeš nekaj "skoraj kot email".
Sicer karkoli drugega ... razni gugli, fejsbuki, slacki, jamrji ... heck, še na irc se je lažje zanašat kot na email ;)
Sicer karkoli drugega ... razni gugli, fejsbuki, slacki, jamrji ... heck, še na irc se je lažje zanašat kot na email ;)
brodul ::
Siol gleda tudi blackliste. Lahko imas ustrezno nastavljen SPF in DKIM. Zavrnejo emaile poslane iz Amazon SES, ce ima lista nastete te IPje.
Pretending to be a mature adult is so exhausting.
zmaugy ::
Siol in email so trije pojmi. Za njih je to tko mimogrede. Če emaila na dobiš in pošiljatelj ni obveščen o tem, njih to ne briga preveč. Zaradi uporabe kakšne res butaste spam liste so (moje izkušnje) pripravljeni odrezati velike tuje telekomunikacijske ponudnike - se pravi zavračati njihove emaile. In pošiljatelj tega velikokrat sploh ne opazi, nakar te čudno gleda, ker mu nisi odgovoril.
Zgodovina sprememb…
- spremenilo: zmaugy ()
ivanl ::
ivanl ::
Evo, dostavo emailov na siol smo zrihtali, pa tukaj napišem kako, če bo kdo (zagotovo bo) imel kaj podobnega kot jaz, se mu ne bo treba ukvarjat 14 dni z katastrofalno potporo na siol-u.
Siol je uvedel nove restrikcije pri prejemanju emailov in sicer:
Njihov spam filter pregleda cel header emaila in če najde karkoli v headerju, ki se ne sklada z "njihovimi" pravili mail enostavno pobrišejo, naslovnik maila ne dobi, pošiljatelj pa ne dobi nobenega obvestila, da njegov email ni bil dostavljen.
Maili iz našega serverja so nemoteno prihajali na vse emaile razen na siolovega ne, vzrok pa je bil header v emailu.
Kot sem že zgoraj dal kodo iz emaila :
Lahko vidite v prvi vrstici, "Received: from blabla.com" to je nosilna domena na VPS-ju ali resseler računu. Oni to pogledajo in preverijo tudi to domeno na spam listah, ter seveda njen SPF zapis. Pri nas se je zgodilo, da smo nosilno domeno preusmerili na nemški server hosteurope.com , kjer pa se po siolovih pravilih SPF-ja ne da tako nastaviti.
Pravilna nasavitev SPF-ja za siol je takole: v=spf1 +a +mx +ip4:193.243.154.28 ~all . Vidite kaj sem odebeljil? Veliko serverjev ima pri znaku ~ , minus in tega se ne da spreminjat. In tako je bilo tudi pri nas.
Mail je bil poslan, vendar pa je siol gledal tudi nosilno domeno in preveril vse o njej, ter seveda našel, da ni po njihovem pravilen SPF in vse emaile pobrisal.
Rešitev je bila ta, da smo zamenjali nosilno domeno.
Drugo je bilo, da se v headerju sporočila pozdarv HELOO ni skladal z njihovim pravilnikom. Ko smo ta pozdrav nastavili tako kot hočejo je stvar čudežno začela delat.
Tretjič pa so na domeni zahtevali vpis hostname serverja. S tem praktično nismo vedeli kaj delat in se nismo niti več ukvarjali, ko je stvar po drugem koraku začela delat.
Po mojem mnenju, kdorkoli uporablja v posloven namene siol email in sodeluje s tujino je obsojen na propad, saj bo redkokateri email prebil skoui njihove spam filtre.
Mi gostujemona Zabec.net in zahvaljujoč njihovemu potrepljenu, zelo dobri podpori in znanju smo zadevo uredili .
LP Ivan
Siol je uvedel nove restrikcije pri prejemanju emailov in sicer:
Njihov spam filter pregleda cel header emaila in če najde karkoli v headerju, ki se ne sklada z "njihovimi" pravili mail enostavno pobrišejo, naslovnik maila ne dobi, pošiljatelj pa ne dobi nobenega obvestila, da njegov email ni bil dostavljen.
Maili iz našega serverja so nemoteno prihajali na vse emaile razen na siolovega ne, vzrok pa je bil header v emailu.
Kot sem že zgoraj dal kodo iz emaila :
<strong>Received: from blabla.com (kuku.si. [193.243.154.28]</strong>) by mx.google.com with ESMTPS id 7si13478247wrj.46.2017.01.17.06.28.30 for <test@gmail.com> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Jan 2017 06:28:31 -0800 (PST) Received-SPF: pass (google.com: domain of test@kuku.si designates 193.243.154.28 as permitted sender) client-ip=193.243.154.28;
Lahko vidite v prvi vrstici, "Received: from blabla.com" to je nosilna domena na VPS-ju ali resseler računu. Oni to pogledajo in preverijo tudi to domeno na spam listah, ter seveda njen SPF zapis. Pri nas se je zgodilo, da smo nosilno domeno preusmerili na nemški server hosteurope.com , kjer pa se po siolovih pravilih SPF-ja ne da tako nastaviti.
Pravilna nasavitev SPF-ja za siol je takole: v=spf1 +a +mx +ip4:193.243.154.28 ~all . Vidite kaj sem odebeljil? Veliko serverjev ima pri znaku ~ , minus in tega se ne da spreminjat. In tako je bilo tudi pri nas.
Mail je bil poslan, vendar pa je siol gledal tudi nosilno domeno in preveril vse o njej, ter seveda našel, da ni po njihovem pravilen SPF in vse emaile pobrisal.
Rešitev je bila ta, da smo zamenjali nosilno domeno.
Drugo je bilo, da se v headerju sporočila pozdarv HELOO ni skladal z njihovim pravilnikom. Ko smo ta pozdrav nastavili tako kot hočejo je stvar čudežno začela delat.
Tretjič pa so na domeni zahtevali vpis hostname serverja. S tem praktično nismo vedeli kaj delat in se nismo niti več ukvarjali, ko je stvar po drugem koraku začela delat.
Po mojem mnenju, kdorkoli uporablja v posloven namene siol email in sodeluje s tujino je obsojen na propad, saj bo redkokateri email prebil skoui njihove spam filtre.
Mi gostujemona Zabec.net in zahvaljujoč njihovemu potrepljenu, zelo dobri podpori in znanju smo zadevo uredili .
LP Ivan
Brane22 ::
Nimam se za nekega guruja za email, ampak po opisanem tebi ne bi zaupal rabljenega zobotrebca.
Siol support ti ni všeč ker te ni podprl postaviti jih v položaj, kjer jih bi jih lažje jebal vsak z 5 min časa samo zato, da bi ja tebi delala neka skripta, dokler selotejp, ki je njen bistveni del, ne razpade.
Siol support ti ni všeč ker te ni podprl postaviti jih v položaj, kjer jih bi jih lažje jebal vsak z 5 min časa samo zato, da bi ja tebi delala neka skripta, dokler selotejp, ki je njen bistveni del, ne razpade.
SeMiNeSanja ::
Me kar zmrazi, ko tole berem. Že v osnovi ne razumem, kako lahko ISP briše maile svojih uporabnikov, ne da bi kjerkoli pustil kakšno sporočilo o tem. Njihova naloga naj bi bila dostava, ne pa samovoljno brisanje.
Kako bi bilo, če bi poštar sam presojal, da bo imel torbo pretežko in vrgel proč vse, kar se mu zdi 'nepotrebna reklama'? Morda še nebi bil prevelik problem, če nebi bi vmes vrgel proč še malo preostale pošte, da bi še malo manj rabil nositi v torbi. Pozablja se pa, da so tudi taki ljudje, ki radi preberejo kakšno reklamo ob jutranji kavi, da vidijo, če je kje kakšna posebna akcija, kako se gibljejo cene,....
Predvidevam, da bodo prejeli toliko pritožb, da bodo kmalu prisiljeni omiliti te svoje omejitve.
Ni mi jasno, zakaj ne morejo vpeljati spam folderja, kot imaš to na Gmail-u. Vse, kar ne ustreza pravilom, pok med spam. Čudo tehnike v letu 2017?
Kako bi bilo, če bi poštar sam presojal, da bo imel torbo pretežko in vrgel proč vse, kar se mu zdi 'nepotrebna reklama'? Morda še nebi bil prevelik problem, če nebi bi vmes vrgel proč še malo preostale pošte, da bi še malo manj rabil nositi v torbi. Pozablja se pa, da so tudi taki ljudje, ki radi preberejo kakšno reklamo ob jutranji kavi, da vidijo, če je kje kakšna posebna akcija, kako se gibljejo cene,....
Predvidevam, da bodo prejeli toliko pritožb, da bodo kmalu prisiljeni omiliti te svoje omejitve.
Ni mi jasno, zakaj ne morejo vpeljati spam folderja, kot imaš to na Gmail-u. Vse, kar ne ustreza pravilom, pok med spam. Čudo tehnike v letu 2017?
Brane22 ::
SeMiNeSanja je izjavil:
Me kar zmrazi, ko tole berem. Že v osnovi ne razumem, kako lahko ISP briše maile svojih uporabnikov, ne da bi kjerkoli pustil kakšno sporočilo o tem. Njihova naloga naj bi bila dostava, ne pa samovoljno brisanje.
To je samo zato, ker nimaš pojma o postopku, ki leži pod tem.
Kako bi bilo, če bi poštar sam presojal, da bo imel torbo pretežko in vrgel proč vse, kar se mu zdi 'nepotrebna reklama'?
Uvedi brezplčano pošto v neomejenih količinah in boš pred natanko istim problemom in z enakimi rešitvami kot pri emailu, vključno z genijalci in njihovimi nasveti o pošti za neprispelo pošto.
No, v realnem svetu take hitro odpravi šus lopate med ušesa prvič, ko zaradi njihovega modrovanja koga zasuje recimo 200 ton pošte. Torej ne samo nabiralnik, ampak bajto, dvorišče in dovozno cesto. nakar se mu usedejo ćez dva tedna na TRR ker ni odgovoril na pisemsko zahtevo da spuca ves ta papir.
Zgodovina sprememb…
- spremenilo: Brane22 ()
zmaugy ::
SeMiNeSanja je izjavil:
Me kar zmrazi, ko tole berem. Že v osnovi ne razumem, kako lahko ISP briše maile svojih uporabnikov, ne da bi kjerkoli pustil kakšno sporočilo o tem. Njihova naloga naj bi bila dostava, ne pa samovoljno brisanje.
Kako bi bilo, če bi poštar sam presojal, da bo imel torbo pretežko in vrgel proč vse, kar se mu zdi 'nepotrebna reklama'? Morda še nebi bil prevelik problem, če nebi bi vmes vrgel proč še malo preostale pošte, da bi še malo manj rabil nositi v torbi.
Tako je. Zaradi Siola sem imel sam že precej velike težave, ko emaili mojih poslovnih partnerjev niso bili dostavljeni, ker je bil nekdo, ki je uporabljal istega ISPja kot kateri od mojih poslovnih partnerjev, zaradi x razloga uvrščen na kakšno spam listo z butastimi pravili, ki jo seveda uporablja tudi Siol.
Na njihovem webmailu si lahko postaviš tudi lastna pravila, eno od niih je tudi "zaupanja vredni pošiljatelji". Če se zgodi prej omenjeni slučaj, si lahko svoja pravila zatakneš nekam, emailov ne boš dobil, v najboljšem primeru bojo šli v spam folder na siol webmailu.
Edina rešitev, ki je delovala, je bila sprememba ponudnika gostovanja pomembnejših email naslovov.
Ni dolgo tega, ko so bili sami deležni doze lastnega zdravila, kar sem opazil, ko mojih emailov (poslanih iz siol emaila) niso dostavili mojemu poslovnemu partnerju, ki je tudi na siol emailu. Razlog je bil ta, da je ena od spam list dala cel Siol na črno listo in Siol to spam listo seveda uporablja in jo je apliciral na pošti svojih naročnikov, nakar so se znašli pred problemom.
Zgodovina sprememb…
- spremenilo: zmaugy ()
SeMiNeSanja ::
@zmaugy - ravno zaradi takih in drugačnih interpretacij 'dopustnega ravnanja s pošto', kot jih imata @Brane22 in SIOL (in še kdo?) že kakšnih 20 let furam svoj lastni mail server. Spam in malware filtriram 3x bolje, kot bodo to oni kdajkoli sposobni, imam popoln pregled nad vsemi maili, ki so mi poslani in nič ne brišem, temveč ves spam shranjujem v posebni karanteni. In kar @Brane22 morda ne bo verjel - tega tudi približno ni toliko, da bi me 'zasulo'..
Ampak baje, da se mi ne sanja o 'postopkih, ki ležijo pod tem'.... (čudi me samo, kako ves ta čas brez težav sprejemam in pošiljam maile, kljub temu, da sem 3x menjal internetnega ponudnika - očitno zgolj srečno naključje, da mi stvari delujejo?)
Morda pa ni mislil tehnične postopke, ampak administrativne, ko se gre kupovati neke 'rešitve', katere niso bile preizkušene v praksi, ampak se slepo, zaradi 'direktive od zgoraj' gre implementirati neke novosti, ki se kasneje izkažejo fail.
Ampak baje, da se mi ne sanja o 'postopkih, ki ležijo pod tem'.... (čudi me samo, kako ves ta čas brez težav sprejemam in pošiljam maile, kljub temu, da sem 3x menjal internetnega ponudnika - očitno zgolj srečno naključje, da mi stvari delujejo?)
Morda pa ni mislil tehnične postopke, ampak administrativne, ko se gre kupovati neke 'rešitve', katere niso bile preizkušene v praksi, ampak se slepo, zaradi 'direktive od zgoraj' gre implementirati neke novosti, ki se kasneje izkažejo fail.
pegasus ::
Problem emaila je, da zanesljivo in po pričakovanjih deluje le v laboratorijskem akademskem laboratoriju, v katerem je bil razvit. Drugi protokoli iz tistih časov so že davno zamrli ali so v umiranju (recimo ftp), le smtp še nekako vztraja in trpinči ljudi še naprej ... "Too big to fail" bi lahko rekel.
Obstaja lep seznam komplikacij, ki jih mora vsaka ideja filtriranja neželene pošte upoštevat ... in ta seznam je direktna posledica dizajna smtp protokola. Ergo, smtpja as is ni mogoče rešiti, potrebujemo nekaj drugega.
Boste koj rekli, "ja na googlu pa vse dela kul" ... drži, a google to rešuje izven smtpja, z metodami, ki si jih zaradi svoje velikosti lahko privošči. Za vse ostale smtpjčke povsod naokrog ... unplug or good luck.
Obstaja lep seznam komplikacij, ki jih mora vsaka ideja filtriranja neželene pošte upoštevat ... in ta seznam je direktna posledica dizajna smtp protokola. Ergo, smtpja as is ni mogoče rešiti, potrebujemo nekaj drugega.
Boste koj rekli, "ja na googlu pa vse dela kul" ... drži, a google to rešuje izven smtpja, z metodami, ki si jih zaradi svoje velikosti lahko privošči. Za vse ostale smtpjčke povsod naokrog ... unplug or good luck.
SeMiNeSanja ::
Pa še to: Če poštarja zalotijo, da je samovoljno vrgel eno samo pismo v smeti, namesto da ga dostavi, bo za to odgovarjal.
ISP pa to lahko počne v velikem formatu, uporabniki pa naj bi mu bili še hvaležni?
Večni izgovor pri tem pa jim je RFC821 iz leta 1982, ki pravi, da SMTP pač ne jamči dostave. Če je ni, je pač ni. Shit happens. Načelo, ki v današnjem poslovnem svetu ni sprejemljivo.
Drugače pa, če se ne motim, se danes uporablja RFC5321. Ta pa pravi tako:
6.1. Reliable Delivery and Replies by Email
When the receiver-SMTP accepts a piece of mail (by sending a "250 OK" message in response to DATA), it is accepting responsibility for delivering or relaying the message. It must take this responsibility seriously. It MUST NOT lose the message for frivolous reasons, such as because the host later crashes or because of a predictable resource shortage. Some reasons that are not considered frivolous are discussed in the next subsection and in Section 7.8. If there is a delivery failure after acceptance of a message, the receiver-SMTP MUST formulate and mail a notification message.
in
As discussed in Section 7.8 and Section 7.9 below, dropping mail
without notification of the sender is permitted in practice.
However, it is extremely dangerous and violates a long tradition and
community expectations that mail is either delivered or returned.
If silent message-dropping is misused, it could easily undermine
confidence in the reliability of the Internet's mail systems. So
silent dropping of messages should be considered only in those cases
where there is very high confidence that the messages are seriously
fraudulent or otherwise inappropriate.
Tu dejansko govorimo o 'silent dropping-u', kjer pa očitno nikogar ne briga, kolikšna je dejanska verjetnost, da se resnično gre za spam, dovolj je že, da sporočilo prekrši enega od parametrov, ki so si jih (ponesrečeno?) sami skonfigurirali.
Brez 'silent dropping-a' bi pošiljateljev poštni strežnik dobil obvestilo, da sporočilo ne gre skozi, ponavadi bi tudi dobil diagnostiko zakaj ne gre in temu ustrezno lahko ukrepa (če ne drugače, ga pošlje z drugega accounta/strežnika). Tako pa se ga pušča v veri, da je sporočilo dostavljeno, sporočila pa nikjer.
Zdaj si pa zamisli, da se to zgodi npr. z naročilom za nek repromaterial, da potem zaradi nedostave na koncu nekje obstoji proizvodna linija in se naredi velika gospodarska škoda.
Ali če npr. nekdo želi ponudbo in tako sporočilo skenslajo. Potencialni kupec nekaj časa čaka, si misli, da ima opravka z neresnim podjetjem in gre k konkurenci.
Me resnično zanima, če bi SIOL pokril poslovno izgubo - ali bi se spet vlačil ven na tisti pradavninski RFC821.
ISP pa to lahko počne v velikem formatu, uporabniki pa naj bi mu bili še hvaležni?
Večni izgovor pri tem pa jim je RFC821 iz leta 1982, ki pravi, da SMTP pač ne jamči dostave. Če je ni, je pač ni. Shit happens. Načelo, ki v današnjem poslovnem svetu ni sprejemljivo.
Drugače pa, če se ne motim, se danes uporablja RFC5321. Ta pa pravi tako:
6.1. Reliable Delivery and Replies by Email
When the receiver-SMTP accepts a piece of mail (by sending a "250 OK" message in response to DATA), it is accepting responsibility for delivering or relaying the message. It must take this responsibility seriously. It MUST NOT lose the message for frivolous reasons, such as because the host later crashes or because of a predictable resource shortage. Some reasons that are not considered frivolous are discussed in the next subsection and in Section 7.8. If there is a delivery failure after acceptance of a message, the receiver-SMTP MUST formulate and mail a notification message.
in
As discussed in Section 7.8 and Section 7.9 below, dropping mail
without notification of the sender is permitted in practice.
However, it is extremely dangerous and violates a long tradition and
community expectations that mail is either delivered or returned.
If silent message-dropping is misused, it could easily undermine
confidence in the reliability of the Internet's mail systems. So
silent dropping of messages should be considered only in those cases
where there is very high confidence that the messages are seriously
fraudulent or otherwise inappropriate.
Tu dejansko govorimo o 'silent dropping-u', kjer pa očitno nikogar ne briga, kolikšna je dejanska verjetnost, da se resnično gre za spam, dovolj je že, da sporočilo prekrši enega od parametrov, ki so si jih (ponesrečeno?) sami skonfigurirali.
Brez 'silent dropping-a' bi pošiljateljev poštni strežnik dobil obvestilo, da sporočilo ne gre skozi, ponavadi bi tudi dobil diagnostiko zakaj ne gre in temu ustrezno lahko ukrepa (če ne drugače, ga pošlje z drugega accounta/strežnika). Tako pa se ga pušča v veri, da je sporočilo dostavljeno, sporočila pa nikjer.
Zdaj si pa zamisli, da se to zgodi npr. z naročilom za nek repromaterial, da potem zaradi nedostave na koncu nekje obstoji proizvodna linija in se naredi velika gospodarska škoda.
Ali če npr. nekdo želi ponudbo in tako sporočilo skenslajo. Potencialni kupec nekaj časa čaka, si misli, da ima opravka z neresnim podjetjem in gre k konkurenci.
Me resnično zanima, če bi SIOL pokril poslovno izgubo - ali bi se spet vlačil ven na tisti pradavninski RFC821.
darkolord ::
@pegasus: alternative so žal še precej manj uporabne.
Zgodovina sprememb…
- spremenilo: darkolord ()
SeMiNeSanja ::
Boste koj rekli, "ja na googlu pa vse dela kul" ... drži, a google to rešuje izven smtpja, z metodami, ki si jih zaradi svoje velikosti lahko privošči. Za vse ostale smtpjčke povsod naokrog ... unplug or good luck.
Kaj nakladaš o Googlu? Kako drugače, kot preko smtp pa pride mail do/od njih?
Vsa stvar je samo v obravnavi, filtriranju, s kakšno ODGOVORNOSTJO se ga lotiš.
Lahko si nastaviš, da se ti fučka za uporabnike in vse pomečeš v koš, ne da bi komu kaj o tem povedal, ali pa se zadeve lotiš na odgovoren način, filtriraš po najboljših močeh in nič ne zavržeš, ne da bi koga o tem obvestil.
pegasus ::
Ja, odgovornost je vodilo vsem postmastrom, a realnost je taka, da si na velikih poštnih strežnikih enostavno ne moreš privoščiti jo implementirati v celoti, ker za to ni financ. Verjemi, vem o čem govorim. Citiran RFC5321 samo bolj na široko in razumljiveje ubesedi to, kar smo razumeli že iz 821. Ko rečeš 250 OK, si sprejel odgovornost za mail. End of story.
zmaugy ::
Dejstvo je, da s Siolom so težave konstantno že nekaj let. Obstajajo tudi ponudniki, kjer v zadnjih letih nisem imel niti enega problema s pošto.
In Siol je najbolj naloudan s kešem.
In Siol je najbolj naloudan s kešem.
neooo ::
laufam lasten mail server, in je to to! se mi ni treba ubadati, če mi kdo bere pošto, ali jo briše... o tem odločam sam!
pegasus ::
Ja, na tem na koncu pristaneš, hočeš ali nočeš.
Manjši uspeh je zgolj to, da imam identičen config že 17 let, pa še kar kljubuje času ...
Manjši uspeh je zgolj to, da imam identičen config že 17 let, pa še kar kljubuje času ...
ivanl ::
SeMiNeSanja je izjavil:
Zdaj si pa zamisli, da se to zgodi npr. z naročilom za nek repromaterial, da potem zaradi nedostave na koncu nekje obstoji proizvodna linija in se naredi velika gospodarska škoda.
Ali če npr. nekdo želi ponudbo in tako sporočilo skenslajo. Potencialni kupec nekaj časa čaka, si misli, da ima opravka z neresnim podjetjem in gre k konkurenci.
Me resnično zanima, če bi SIOL pokril poslovno izgubo - ali bi se spet vlačil ven na tisti pradavninski RFC821.
To se je tudi zgodilo, sicer gospodarske škode ni bilo, ker so se slišali po telefonu, lahko pa bi bila in to ne majhna. Malo razmišljamo celo o tožbi, vendar nimamo ne časa ne volje, da se v to spustimo.
Drugače pa zadeva sploh nebi bila tako tečna, če bi njihova podpora delovala, ampak ne. Kličeš na tisto št. 0801000 in se ti zmeraj oglasi nek drug študentek, ki bere njihov help. Pošlješ email, ti ga spet nazaj pošlje nek študentek, ki je dobil neko sporočilo od poštnih administratorjev, ti pa so dobili neko sporočilo od ne vem koga. V glavnem, osebe s katerimi komuniciraš nimajo pojma. V telefon sem tulil na njih, ker mi je odprlo vse ventile, oni na drugi strani pa lepo ležerno in počasi razlagajo kako zadeva (ne)funkcionira s tem, da mi 10 dni niso znali povedati zakaj pošta iz naših serverjev ne gre skozi.
Stvar se je obrnila šele v torek, ko smo pogledali kdo je direktor IT-ja na telekomu, mu napisali priporočeno pismo z razlago kaj se grejo, ter z grožnjo o tožbi za gospodarsko škodo. Ter naročili trem strankam, naj jim pošljejo še same email o nedostavljvosti emailov. Takrat so nas začeli celo oni klicati nazaj in zgodilo se je, da smo dvakrat dobili klic od dveh, ki sta dejansko nekaj vedela o težavi, ki jo imajo. Eden mi je celo rekel "a iz tujine ne dobite emailov, a ne" , se pravi, da tudi sami vedo za težavo, ampak jebe s jim, oni dobijo svojo plačo, če jim zmanjka denarja, bomo pa itak vsi firmo dokapitalizirali s kakšno miljardo.
Ni pa samo email z domeno @siol.net težava, dovolj je, da ima podjetje ali kdorkoli gostovanje na telekomu in domeno blabla.com pa že pade pod njihove filtre za pošto. En tak primer je ip-posocje.si , tudi oni niso dobivali emailov od ene naše stranke.
laufam lasten mail server, in je to to! se mi ni treba ubadati, če mi kdo bere pošto, ali jo briše... o tem odločam sam!
Ni mi ravno najbolj jasna ta strategija? Če pošiljaš email "(ne)pravilno" na siol maile, jih ravno tako ne boš dostavil? Ali se motim?
Sam sem programer, zato kar priznam, da se na protokole in emaile itd... ne spoznam v nulo, s tem namenom imamo tudi gostovanje v najemu, da nam take težave pomagajo rešiti drugi, vsega pač ne moreš delati sam.
LP Ivan
P.S. Nesposobni so sposobni onesposobiti sposobne ;-)
Zgodovina sprememb…
- spremenil: ivanl ()
SeMiNeSanja ::
Pri 'ta velikih' je vedno problem prva linija podpore, kjer imajo postavljene študentke z omejenim znanjem, ki si ne upajo eskalirati težave in te posredovati naprej do prave osebe, katera se dejansko razume v področje, na katerem imaš težavo. Če nisi vztrajen in ne zahtevaš, da te posredujejo do admina pošte/ dns/..., se lahko reševanje težave zavleče v nedogled. Če poleg tega še sam nisi ekspert na problematičnem področju, si pa sploh pečen.
Ampak tudi manjši imajo svoje težave. Kolega je teden dni pred novim letom pri enemu od 'ta malih' zahteval, da mu spremenijo MX zapis na DNSu, pa mu niso mogli ustreči, ker je tista oseba, ki to dela - na dopustu! Ravnokar preveril - MX zapis še vedno ni popravljen! Stvar, ki jo jaz pri sebi popravim v 5 minutah, po treh tednih še vedno ni zrihtana.
Ampak tudi manjši imajo svoje težave. Kolega je teden dni pred novim letom pri enemu od 'ta malih' zahteval, da mu spremenijo MX zapis na DNSu, pa mu niso mogli ustreči, ker je tista oseba, ki to dela - na dopustu! Ravnokar preveril - MX zapis še vedno ni popravljen! Stvar, ki jo jaz pri sebi popravim v 5 minutah, po treh tednih še vedno ni zrihtana.
Zgodovina sprememb…
- spremenilo: SeMiNeSanja ()
Vredno ogleda ...
Tema | Ogledi | Zadnje sporočilo | |
---|---|---|---|
Tema | Ogledi | Zadnje sporočilo | |
» | LinkedIn spam?Oddelek: Loža | 2724 (2156) | kunigunda |
» | Čuden emailOddelek: Loža | 4505 (3754) | Vice |
» | Lastni poštni strežnik(kako ne biti označen kot spam)Oddelek: Omrežja in internet | 3331 (2891) | BlackPanx |
» | Pošta z mojega e-naslova v spamOddelek: Omrežja in internet | 1972 (1587) | francy |
» | [Ubuntu server] mail poslan iz serverja zazna kot vsiljeno pošto (strani: 1 2 )Oddelek: Omrežja in internet | 9121 (8091) | shorvat |