Si tratta di statistica. Hotmail si aspetta che il 99% delle email che mandi le mandi a persone che conosci e quindi l'indirizzo esiste. Se mandi troppe email ad indirizzi invalidi ti abbassa la reputazione e ti mette in spam.

Per uscire dallo spam devi riaumentare la reputazione e lo si fa inviando email (non stando fermi). Devi mandare email a persone che esistono e che vogliono ricevere le tue email e che andranno a cercarsi la mail nello spam e marcarla come non spam. Basta che siano pochi a cercarla tra lo spam e nessuno a marcarne invece delle nuove come spam e vedrai che ne esci.

Considera sempre che per i mail server un IP che non invia mail e poi d'un tratto comincia ad inviarle in massa è al 99% uno spammer e come tale viene trattato. Colpevole fino a prova contraria, si potrebbe dire.

Ciao Bago, ho inserito un pò di header che mi consigliavi in un altro post, ho modificato gli rDNS ed adesso devo solo sistemare il record spf.

Trovi altre cose da cambiare in questi header di quest'email?

Delivered-To: [email protected]
Received: by 10.216.38.131 with SMTP id a3cs9422web;
Wed, 10 Mar 2010 00:27:59 -0800 (PST)
Received: by 10.204.130.155 with SMTP id t27mr746315bks.134.1268209678164;
Wed, 10 Mar 2010 00:27:58 -0800 (PST)
Return-Path: [email protected]
Received: from serverdedica64 (nome.dominio.it [xx.xx.xx.xx])
by mx.google.com with ESMTP id 25si3226614bwz.76.2010.03.10.00.27.57;
Wed, 10 Mar 2010 00:27:57 -0800 (PST)
Received-SPF: error (google.com: error in processing during lookup of [email protected]: DNS timeout) client-ip=xx.xx.xx.xx;
Authentication-Results: mx.google.com; spf=temperror (google.com: error in processing during lookup of [email protected]: DNS timeout) [email protected]
Received: from serverdedica64 (localhost.localdomain [127.0.0.1])
by serverdedica64 (8.13.8/8.13.8) with ESMTP id o2A8Sede009312
for [email protected]; Wed, 10 Mar 2010 09:28:40 +0100
Received: (from apache@localhost)
by serverdedica64 (8.13.8/8.13.8/Submit) id o2A8SdiT009311;
Wed, 10 Mar 2010 09:28:39 +0100
Date: Wed, 10 Mar 2010 09:28:39 +0100
To: [email protected]
Subject: Ciao! Email prova
From: Nome [email protected]
Reply-To: [email protected]
Message-ID: [email protected]
X-Mailer: PHP v5.1.6
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
List-Unsubscribe: xxxx://xxx.dominio.it/cancellazione.php

Sì.

1. Usa un indirizzo email vero e non noreply@ come mittente: un dialogo è per definizione bidirezionale e l'email non è uno strumento di broadcast. Questo vale sia per questioni tecniche che per questioni di marketing.

2. Come vedi Google ha avuto un timeout sul dns cercando di sapere qualcosa del tuo dominio: MALE. Se questa cosa capita spesso è un male non solo per la tua posta ma anche per il tuo web e tutti gli altri servizi legati al dominio. Non dovrebbe MAI capitare.

3. Potresti aggiungere un "Precence: bulk". Google lo suggerisce per le email massive. (hotmail non credo lo consideri).

4. il vero nome di "serverdedica64" può essere importante: deve avere pochi numeri. La risoluzione inversa del suo IP deve essere "serverdedica64" (come il nome originale). Il server smtp dovrebbe usare lo stesso nome quando si connette ai server remoti (durante l'HELO/EHLO).

DKIM per ora lascialo per ultimo: ti serve solamente per attivare il Feedback Loop di yahoo. Importante in generale per l'igiene della lista, ma inutile nei confronti di Hotmail.

Grazie della risposta Bago.

1. se metto come return-path un indirizzo tipo [email protected] e come from un altro indirizzo per ricevere le risposte le mail bounced andranno tutte nell'indirizzo giusto?

2. Questa me la devo studiare..

3. Precence: bulk a quanto ho letto serve per mail masive tutte uguali tipo newsletter, io mando un alto numero di mail giornaliere ma ognuna differente dall'altra essendo delle notifiche personalizate generate dal sistema. In questo caso non dovrebbe essere necessario credo.

4. Questo credevo di averlo già risolto avendo modificaro i rDNS ed ottenendo come riultato questo:
   da >
   Received: from miodominio.it (hostMIO-IP.serverdedicati.aruba.it [MIO.IP])
   a >
   Received: from serverdedica64 (nome.dominio.it [MIO.IP])

1. Sì. A parte quelli che non seguono gli standard, tipo qualche messaggio di out of office o auto reply. In ogni caso le risposte dei destinatari non solo dovrebbero essere gradite, ma piuttosto incentivate: lo sapevi per esempio che per google il fatto che un utente risponda alle tue email viene considerato in maniera positiva nel calcolo della tua reputazione?

2. Io lo uso per tutti quei messaggi che non sono strettamente transazionali. Distinguere in due tipologie fa si che eventuali blocchi/limitazioni riguardino le email "massive" mentre le transazionali continuino a passare anche in casi di limitazione.

3. non so se "serverdedica64" è il nome vero o solo un placeholder che hai messo per offuscare il nome reale. Comunque la cosa migliore sarebbe che "from serverdedica64 (nome.dominio.it [xx.xx.xx.xx])" diventasse "nome.dominio.it (nome.dominio.it [xx.xx.xx.xx])". In ogni caso MOLTO meglio ora rispetto al precedente.

Marmotta, i Feedback Loop di Hotmail li processi? Hotmail, oltre a quello, conteggia per ogni IP i "trap hits" che non sono esattamente spam trap, perchè includono anche indirizzi obsoleti (disattivati, abbandonati...).

Altra domanda: l'IP di Aruba usato per inviare le email è dedicato a te o condiviso con altri?

@bago said:

1. Sì. A parte quelli che non seguono gli standard, tipo qualche messaggio di out of office o auto reply. In ogni caso le risposte dei destinatari non solo dovrebbero essere gradite, ma piuttosto incentivate: lo sapevi per esempio che per google il fatto che un utente risponda alle tue email viene considerato in maniera positiva nel calcolo della tua reputazione?

3. Io lo uso per tutti quei messaggi che non sono strettamente transazionali. Distinguere in due tipologie fa si che eventuali blocchi/limitazioni riguardino le email "massive" mentre le transazionali continuino a passare anche in casi di limitazione.

4. non so se "serverdedica64" è il nome vero o solo un placeholder che hai messo per offuscare il nome reale. Comunque la cosa migliore sarebbe che "from serverdedica64 (nome.dominio.it [xx.xx.xx.xx])" diventasse "nome.dominio.it (nome.dominio.it [xx.xx.xx.xx])". In ogni caso MOLTO meglio ora rispetto al precedente.

1. non lo sapevo, mi avevi comunque già convinto
2. mi sa allora che anche qui seguirò il tuo consiglio
3. Questo visto che non è una cosa che posso modificare io e che comunque già dovrebbe andare bene perora lo lascio così per poter ripartire prima possibile con l'invio delle mail, poi con un pò più di calma cercherò di ottimizzare anche questo.

2. Come vedi Google ha avuto un timeout sul dns cercando di sapere qualcosa del tuo dominio: MALE. Se questa cosa capita spesso è un male non solo per la tua posta ma anche per il tuo web e tutti gli altri servizi legati al dominio. Non dovrebbe MAI capitare.

sapresti darmi qualche indizio sulla possibile motivazione su questo timeout?

@Nazzareno said:

Marmotta, i Feedback Loop di Hotmail li processi? Hotmail, oltre a quello, conteggia per ogni IP i "trap hits" che non sono esattamente spam trap, perchè includono anche indirizzi obsoleti (disattivati, abbandonati...).

Altra domanda: l'IP di Aruba usato per inviare le email è dedicato a te o condiviso con altri?

Ciao Nazzareno, i feedback loop di hotmail ancora no, ma è una cosa alla quale mi dedicherò non appena avrò risolto le altre cose di cui ho scritto sopra.

Gli ip di aruba sono 2 e sono usati esclusivamente da me.

Dal mio punto di vista attivare i Feedback Loop oltre che gestire correttamente i bounce è prioritario rispetto a DKIM e il List-Unsubscribe!

Se invio un email dal mio server ad un account freemail o jumpy che sono ormai chiusi o a qualcosadiinesistente#yahoo.it e come returnpath hanno come indirizzo bounce#miodominio.it quanto tempo ci vuole perchè ritornino indietro? Ho già fatto questa prova ma non trovo mai nulla nella casella bounce.

Dipende: se il messaggio viene rimbalzato a livello di connessione smtp, dovrebbe essere immediato. Infatti è il server che spedisce che genera il bounce in base alla risposta del server di destinazione.

Prova a vedere sul tuo server di invio: se i messaggi sono ancora in coda significa che il server ci sta riprovando, magari ci riprova per 3 giorni prima di rinunciare e restituirti un bounce definitivo. Potrebbe, se configurato, inviarti un bounce (soft, quindi codice 4**) anche per ogni tentativo non andato a buon fine.

Nel caso invece - molto più remoto e improbabile - che il server di destinazioni accetti il tuo messaggio nonostante destinato ad un indirizzo non esistente o disattivato, è possibile che opti per un silent drop: il tuo messaggio verrà cestinato senza che ti arrivi alcun bounce di risposta. In caso contrario si renderebbe colpevole di backscattering.