Siuntimo taisyklės ir ribos e-mails
Informacija apie elektroninių pranešimų siuntimo iš Web Hosting, WebSite, Mailhosting ir iš virtualių ar skirtųjų serverių taisykles ir ribas.
Siekiant užkirsti kelią nepageidaujamų elektroninių pranešimų (šlamšto) siuntimui ir jį riboti, visoms mūsų prieglobos paslaugoms taikomos tam tikros taisyklės. Šios ribos padeda apsaugoti mūsų bendrai naudojamų pašto serverių reputaciją, ypač pažeistų pašto dėžučių ar interneto formų atveju.
Web Hosting, WMS, WebSite, Mailhosting
Griežtai draudžiama iš Web Hosting, WMS, WebSite ir Mailhosting paslaugų siųsti bet kokio pobūdžio masinius el. laiškus, nepriklausomai nuo to, ar laiškai yra pageidaujami, ar nepageidaujami. Tai apima tiek masinius komercinius pasiūlymus, tiek naujienlaiškius, siunčiamus prenumeratoriams.
Jei jums reikia siųsti tokio pobūdžio paštą, įsirenkite paslaugą, kuri specializuojasi masiniame pašto siuntime (VEDOS nesiūlo, netarpininkauja ir nerekomenduoja jokios tokios paslaugos), arba galite susikurti savo pašto serverįVPS or dedicated server.
Svetainių prieglobos paslauga, WMS ir WebSite el. laiškus siunčia dviem būdais:
Funkcija mail() PHP kalboje
From the web hosting server using the mail() function in PHP. This includes many contact forms, WordPress password recovery, and various other, at least partially automated, messages.
Sending via SMTP
Iš el. pašto programos per mūsų SMTP serverį. Norint taip išsiųsti el. laišką, reikia prisijungti prie pašto dėžutės su naudotojo vardu ir slaptažodžiu.
Mailhosting leidžia siųsti el. laiškus tik per SMTP. Naudojant svetainių prieglobą ir WMS, neįmanoma siųsti neautorizuotų el. laiškų per SMTP protokolą (išeinamojo ryšio per TCP prievadą 25 užmegzti negalima). Norint siųsti paštą per SMTP protokolą iš interneto programos, jį reikia siųsti autorizuotai (t. y. prisijungus) per mūsų pašto serverį arba trečiosios šalies serverį 587 prievadu.
Limits on sending e-mails for hosting services
The following table summarizes the limits on sending e-mails for hosting services:
| Limit | Web Hosting NoLimit/Extra, WebSite (except Free), WMS |
Web Hosting LowCost | Mailhosting Individual | Mailhosting Business (can be activated for any Web Hosting) |
|---|---|---|---|---|
| Maximum number of e-mails sent via PHP per day | 500 | 50 | – | – |
| Maximum number of e-mails sent via SMTP per day | 500 | 50 | 500 | 2500 |
| Maximum size of an e-mail sent, including attachments (MB) | 100 | 100 | 100 | 100 |
If you try to send an e-mail above the set limit
- Interneto paslaugų
mail()function in PHP returnsfalseand the server discards the message. - The SMTP server rejects the message with an error message informing you that the limit has been exceeded.
The limit applies to a calendar day; the counter resets every day at midnight (CET/CEST).
The stated limits on sent e-mails can only be increased by purchasing the add-on service Upgrade to the Business variant. There is no entitlement to a limit increase, and the provider reserves the right to refuse a request for an increase (or for provision of the add-on service) even without giving a reason. Increasing the limit does not permit bulk sending of e-mail messages, nor does it justify it in any way.
Virtualieji ir dedikuotieji serveriai
You can use VPS and dedicated servers for the bulk sending of solicited messages, provided you meet the following conditions:
- The messages must be solicited, meaning the recipients must be aware that they have signed up to receive these messages.
- Messages must be sent in a non-intrusive volume.
- Messages must be sent in reasonably small batches, never all at once in large quantities.
- The message must include a procedure for unsubscribing, and the sender must accept and respect unsubscribe requests.
Information the customer is required to provide at our request
- Kaip gaunami gavėjų el. pašto adresai ir kaip gaunamas sutikimas siųsti pranešimus.
- What messages are being sent.
- How often the messages are sent.
- In what volume they are sent (total number, sending rate).
- How recipients can unsubscribe.
- Any other information at our request.
If the customer violates these conditions or fails to provide us with the required information, we are entitled to completely block e-mail sending or suspend the entire server.
Why these limits?
First of all, it should be emphasized that these limits are not primarily aimed at our customers. Common causes and sources of spam include:
- A security hole in a PHP script that allows it to be exploited, for example the bulk insertion of posts into a discussion forum (the forum then sends these new posts to its members), a bug directly in a contact form, and similar.
- Interneto svetainės FTP slaptažodžio vagystė (dažniausiai iš užkrėsto namų kompiuterio); tuomet užpuolikas kliento svetainėje patalpina kenkėjišką PHP scenarijų, per kurį vėliau siunčia masinį šlamštą. Klientas gali net nenutuokti, kad tai vyksta.
- Kliento PHP scenarijaus klaida, dėl kurios jis, pavyzdžiui, įstringa cikle ir pradeda netikėtai bei intensyviai siųsti el. laiškus.
Deliberate sending of spam by our customer is the last thing that happens and the last thing we deal with.
So why these limits? Web Hosting, WMS, WebSite ir Mailhosting el. pašto paslaugos yra bendrinamos. Viename serveryje talpinamos kelių šimtų klientų interneto svetainės arba pašto dėžutės. Jei toks serveris (dėl kokios nors priežasties) pradeda siųsti masinius laiškus ir dėl to jį užblokuoja gavėjo el. pašto serveris, laikinai ar net visam laikui bus užblokuoti ir visi kiti to paties serverio klientai (nes jie visi naudoja tą patį IP adresą).
Jei tokį blokavimą nustato stambus el. pašto paslaugų teikėjas, pavyzdžiui, Seznam, Gmail ar Outlook, didelė dalis naudotojų ir klientų negaus iš to serverio net teisėtų žinučių, kol situacija nebus ištaisyta ir adresas atblokuotas. Tai gali užtrukti valandas ar net ilgiau.
Why aren’t the limits addressed only once something happens? The solution must be preventive. If an attacker finds a security gap in a website or e-mail account and starts exploiting it for bulk spamming, it is already too late. Sending tens of millions of messages is a matter of a single script and a relatively short amount of time. By the time we received and processed a report, such a server would already be blocked in various places across the Internet.
This solution is not a bad thing. Nelaikykite to prieš jus nukreiptu apribojimu. Laikykite tai savo apsauga nuo to, kad jūsų svetainė būtų panaudota neteisėtai veiklai. Dėl šios prevencinės priemonės galime užtikrinti, kad iš jūsų svetainės tinkami, pageidaujami el. laiškai visada pasiektų jūsų klientus, draugus, lankytojus ir taip toliau. Be šio limito tai galbūt nebūtų įmanoma.