Regole e limiti per l’invio e-mails

Informazioni sulle regole e sui limiti per l’invio di messaggi e-mail da Web Hosting, WebSite, Mailhosting e da server virtuali o dedicati.

Per prevenire e limitare l’invio di messaggi e-mail non richiesti (spam), per tutti i nostri servizi di hosting valgono determinate regole. Questi limiti servono a proteggere la reputazione dei nostri server di posta condivisi, soprattutto in caso di caselle di posta o moduli web compromessi.

Web Hosting, WMS, WebSite, Mailhosting

L’invio di messaggi e-mail di massa di qualsiasi tipo dai servizi Web Hosting, WMS, WebSite e Mailhosting è severamente vietato, indipendentemente dal fatto che i messaggi siano sollecitati o non sollecitati. Vi rientrano sia le offerte commerciali di massa sia le newsletter inviate a destinatari iscritti.

Se hai bisogno di inviare posta di questo tipo, attiva un servizio specializzato nell’invio massivo di posta (VEDOS non offre, non intermedia e non raccomanda alcun servizio di questo tipo), oppure puoi configurare il tuo server di posta su unVPS or dedicated server.

Web hosting, WMS e WebSite inviano e-mail in due modi:

La funzione mail() in PHP

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

Da un software di posta elettronica tramite il nostro server SMTP. Per inviare un’e-mail in questo modo è necessario accedere alla casella di posta con nome utente e password.

Il mailhosting consente l’invio di e-mail solo tramite SMTP. Con il webhosting e WMS non è possibile inviare e-mail non autorizzate tramite il protocollo SMTP (non è possibile stabilire una connessione in uscita sulla porta TCP 25). Per inviare posta tramite il protocollo SMTP da un’applicazione web è necessario inviarla in modo autorizzato (cioè dopo il login) tramite il nostro server di posta o quello di terze parti sulla porta 587.

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

  • Il mail() function in PHP returns false and 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.

Server virtuali e dedicati

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

  • Come vengono ottenuti gli indirizzi e-mail dei destinatari e come viene ottenuto il consenso all’invio dei messaggi.
  • 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.
  • Furto della password FTP di un sito web (di solito da un PC domestico infetto); l’aggressore colloca quindi uno script PHP dannoso sul sito web del cliente, attraverso il quale invia successivamente spam di massa. Il cliente può non avere la minima idea che ciò stia accadendo.
  • Un errore nello script PHP del cliente che, per esempio, si blocca in un ciclo e inizia a inviare e-mail in modo inatteso e intensivo.

Deliberate sending of spam by our customer is the last thing that happens and the last thing we deal with.

So why these limits? I servizi di posta elettronica di Web hosting, WMS, WebSite e Mailhosting sono condivisi. Su un unico server sono ospitati i siti web o le caselle di posta di diverse centinaia di clienti. Se un tale server inizia (per qualsiasi motivo) a inviare messaggi di massa e viene successivamente bloccato dal server di posta del destinatario, anche tutti gli altri clienti sullo stesso server verranno bloccati temporaneamente o persino in modo permanente (perché condividono tutti lo stesso indirizzo IP).

Se un blocco di questo tipo viene impostato da un grande fornitore di servizi e-mail come Seznam, Gmail o Outlook, un gran numero di utenti e clienti non riceverà da quel server nemmeno i messaggi legittimi, finché la situazione non verrà risolta e l’indirizzo sbloccato. Questo può richiedere ore, o anche di più.

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. Non lo prenda come una restrizione rivolta contro di lei. Lo consideri piuttosto come la sua protezione contro l’uso improprio del suo sito web per attività illegali. Grazie a questa misura preventiva siamo in grado di garantire che dal suo sito web le e-mail giuste e desiderate arrivino sempre ai suoi clienti, amici, visitatori e così via. Senza questo limite ciò potrebbe non essere possibile.

Torna su