---

 

Šie reikalavimai yra sukurti, kad atitiktų globalios darbo grupės dalyvių išvystytus ir priimtus standartus dėl kovos su spam, sukčiavimo ir kitų formų elektroninių nusikaltimų.

Reikalavimų nesilaikymas gali sąlygoti tai, kad Jūsų laiškas dalinai ar visiškai nebus pristatytas. 

Techniniai reikalavimai

• Visi el.laiškai privalo atitikti RFC standartus (pvz., SMTP 5321; MIME 2045, 2046, 2047, 2048,2049;)
• Visi el.pašto serveriai, kurie jungiasi su inbox.pk privalo turėti galiojantį, jautrų, ne automatiškai sugeneruotą DNS įrašą (rDNS, PTR-records). Kontaktinės IP adresų detalės WHOIS privalo būti susijusios ir prieinamos.

 

• Visi pašto serveriai, kurie jungiasi su inbox.pk pašto serveriais turi būti tinkamai apsaugoti nuo neautorizuoto or anoniminio panaudojimo. Įsitikinkite, kad Jūsų serveris nėra atidaryto ar atviro transliavimo.
• Įsitikinkite, kad visos interneto formos Jūsų svetainėse yra saugios.
• Jeigu naudojate laiškų siuntimo interneto forma šifruotes, įsitikinkite, kad jos negali būti naudojamos spam laiškų siuntimui;
• Tiesioginis prisijungimas prie inbox.pk MX-pašto serverių iš dinaminių IP adresų ar namų tinklų adresų yra negalimas;
• inbox.pk MX-įrašai negali būti koduojami siuntėjo serverių fonfigūracijos failuose;
• Naudodami HTML savo įrašuose, įsitikinkite, kad galioja HTML dokumento struktūra. Draudžiama naudoti potencialiai pavojingus objektus, kaip pavyzdžiui JavaScript, VBScript, Java-applets, Frames ir IFrames; Prijungtus prie išorinių puslapiųCSS, Meta Refresh, t.t.. (dėl šių elementų naudojimo bus blokuojami Jūsų laiškai);
• Bandymas naudoti trečių šalių paslaugas (redirectors, "URL shorteners") dengiant informaciją apie pirminį puslapį, taip pat bet kokias nurodas laiške, gali įtakoti laiškų blokavimą;
• Koduoti URL  IP adresai ir domenų pavadinimai yra draudžiami naudoti kaip laiškų nuorodos.

 

Administraciniai reikalavimai

• Pašto paslauga turi būti vykdoma  išskirtinai gavus aiškų ir tiesioginį adresato prašymą ar sutikimą (opt-in);
• Visų prenumerata siunčiamų laiškų tekste privalo būti įtraukta galiojanti ne elektroninė kontaktinė informacija apie prenumeruojamą bendrovę, įskaitant telefono numerį ir fizinį adresą.
• Prenumeratos atsisakymo procesas turi būti aiškus, nekompleksinis, kaip pavyzdžiui slaptažodžio vedimas ar atskleidimas, registracija ir panašiai. Mes rekomenduojame pridėti aiškiai matomą nuorodą su galimybe atsisakyti prenumeratos vienu paspaudimu kiekviename laiške. Vartotojai neturi identifikuoti savęs svetainėje, norėdami atsisakyti prenumeratos.
• Laiškų siuntėjai neturi būti įtraukti į slėpimo, klastojimo, iškraipymo sąrašus ir šaltinius;
• Prenumeratos informacija, įskaitant metodą, kaip el.pašto adresas buvo gautas, data ir prenumeratos laikas, taip pat IP adresas, iš kurio vartotojas patvirtino prenumeratą, turi būti prieinama vartotojui pareikalavus.
• Prenumeratos laiškai privalo įtraukti informaciją apie tai, kaip vartotojo adresas buvo gautas ir vartotojo sutikimas gauti prenumeratos laiškus. Pavyzdžiui: „Jūs gaunate šią žinutę, nes užsiprenumeravote mūsų svetainėje...“;
• Paslaugos, siunčiančios prenumeratos laiškus, turi pašalinti prenumeratorius iš duomenų bazės arba imtis kitų veiksmų, kad laiškų siuntimas būtų nutrauktas adresams, kurie generuoja SMTO protokolo klaidą 550: vartotojas nerastas (vartotojo aktyvumo bazės sekimas yra būtina sąlyga, savo reputaciją saugančiam laiškų siuntėjui )

Vartotojų skundai, siuntimas neegzistuojantiems kontaktams (taip pat ir egzistavusiems, bet ištrintiems), negalimumas siuntėjui gauti nepristatymo ataskaitų ir jeigu žinutės patenka į inbox.pk spam filtrus – gali įtakoti neigiamą siuntėjo reputaciją. Galimybė pristatyti laiškus į inbox.pk  gali būti išjungta bet kuriam siuntėjui, įskaitant neigiamos reputacijos požymį.

Serija to paties siuntėjo pažeidimų gali turėti įtakos daliniam ar visiškam IP adresų inbox.pk blokavimui.

 

---

Jei neradote atsakymo, susisiekite su mumis

---