- Home
- Categorie
- Digital Marketing
- Email Marketing e Messaggistica
- Mi considerano spam
-
Scusate il ritardo ecco gli header:
Delivered-To: [email protected] Received: by 10.223.116.130 with SMTP id m2cs39238faq; Fri, 16 Oct 2009 14:13:52 -0700 (PDT) Received: by 10.150.114.14 with SMTP id m14mr3645864ybc.162.1255727631498; Fri, 16 Oct 2009 14:13:51 -0700 (PDT) Return-Path: <[email protected]> Received: from titan.apthost.com (titan.apthost.com [174.120.159.138]) by mx.google.com with ESMTP id 19si3567981gxk.49.2009.10.16.14.13.50; Fri, 16 Oct 2009 14:13:51 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of [email protected] designates 174.120.159.138 as permitted sender) client-ip=174.120.159.138; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of [email protected] designates 174.120.159.138 as permitted sender) [email protected] Received: from idiotcli by titan.apthost.com with local (Exim 4.69) (envelope-from <[email protected]>) id 1Myu6o-0001Sp-4t for [email protected]; Fri, 16 Oct 2009 16:13:10 -0500
Quest' email va a finire diritta diritta in SPAM ed è l' email che riceve l' utente dopo la registrazione
-
Sembra tutto a posto: l'ip non è in blacklist e la reputazione neutrale. Il best-guess record di SPF passa. Però ti dicevo se ci postavi sia gli header di quella che arriva che di quella che non arriva. Poi mi sembra manchino parecchi header (mime/content type/subject/from/sender)... offuscali magari, ma postali.
-
Ecco gli altri:
X-PHP-Script: ww.miosito.com/index.php for 62.98.56.203 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: 8Bit X-Mailer: Drupal Errors-To: [email protected] From: [email protected] Message-Id: <[email protected]> Date: Fri, 16 Oct 2009 16:13:10 -0500 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - titan.apthost.com X-AntiAbuse: Original Domain - gmail.com X-AntiAbuse: Originator/Caller UID/GID - [578 32003] / [47 12] X-AntiAbuse: Sender Address Domain - titan.apthost.com X-Source: /usr/bin/php X-Source-Args: /usr/bin/php /home/yyy/public_html/miosito.com/index.php X-Source-Dir: miositoprincipale.com:/public_html/miosito.com
L' email che arriva e che non arriva è sempre questa. A volta va in SPAM e a volte no.
Grazie mille speriamo di risolvere
-
Nel primo messaggio dicevi che le email del primo sito finivano in spam mntre quelle del secondo no, per questo ti ho chiesto gli header.
Se invece sono email identiche dello stesso sito che a volte finiscono in spam e a volte no, allora google sta cercando ancora di capire se sei uno spammer o meno. Se molti utenti andranno a recuperare la tua email dallo spam marcandola come non spam allora probabilmente smetterà di metterle in spam.
L'interazione degli utenti con le tue email (anche quelle che non finiscono in spam) può essere importante: se l'utente clicca, le apre, visualizza le immagini aumenterà la tua reputazione.
Per il resto non c'è molto che puoi fare: potresti pubblicare i record SPF per il tuo dominio (ma questo sarà più per Hotmail che per Gmail) e potresti firmare i messaggi uscenti con DKIM, ma non so se la miglioria ottenibile per un piccolo volume di email giustifica l'impazzimento tecnico.
-
Eh infatti mi ero sbagliato: Tutte le email a volte finiscono in spam e a volte no.
Il problema è che io non posso aspettare che google decida se sia spam o meno.
Sul mio sito si registrano in media 100 utenti al giorno e il 60% di questi non cliccano sull' email di verifica.Forse cambiando hosting risolverei ?
P.s. per ora ho disabilitato l' email di verifica dopo la registrazione
-
Perdere iscritti in questo modo non è bello, così come non è consigliabile disabilitare l'email di verifica, poichè potresti ritrovarti con indirizzi errati, utenti che pensano di essersi iscritti e invece hanno lasciato un'email errata, utenti iscritti loro malgrado a causa di errori di altri o peggio spam trap iscritte da parte di tuoi concorrenti.
Prova a spedire, almento le email di verifica iscrizione (in gergo chiamata iscrizione COI: Confirmed Opt In), con un sistema differente. Abbiamo diversi clienti che usano i web service di MailUp proprio per quello, ad esempio nel settore gambling e scommesse online.
L'uso di un sistema professionale, anche se limitatamente all'email di conferma iscrizione, permette di sfruttare lo stato dell'arte del delivery (Spf, Dkim, List-Unsubscribe, whitelisting, auto-filtering, monitoring, FBL, tracking...) senza dover implementare tutto in casa.
-
Usare un servizio professionale per la consegna per l' email gia mi era passato per la testa... ma almeno per l' email di conferma di iscrizione volevo evitare.
Non c'è altra soluzione ?
Devo cambiare hosting ?
-
Allora, direi che il problema principale potrebbe essere il tuo return-path che non assomiglia nemmeno vagamente al tuo from/sender e probabilmente il fatto che tu non leggi la mail che rimbalza su quel return path altrimenti probabilmente sapresti anche perchè google sta rifiutando le tue email.
Quindi, cerca di capire con il tuo hoster se hai la possibilità di inviare email che abbiano te come mittente (il return path è ciò che viene messo come mittente in smtp) o, per lo meno, assicurarti che le email inviate all'indirizzo di return-path le puoi leggere.
Aggiungere l'header List-Unsubscribe potrebbe aiutare, ma questo probabilmente c'è scritto nel messaggio di bounce che google sta inviando a quell'indirizzo.
Se non riesci a sistemare php per fare l'invio con il returnpath corretto una soluzione alternativa potrebbe essere quella di usare il modulo smtp di drupal (drupal.org/project/smtp) che ti permette di bypassare il comando mail di php (che usa i meccanismi interni di php e la configurazione dell'hoster) usando invece un server SMTP a tua scelta (magari sempre la tua stessa macchina se ha un server SMTP, oppure quello del tuo provider).
-
Il cambio di hosting è comunque laborioso e non è detto che sia risolutivo. A questo punto potresti anche acquistare un servizio smtp o hosting da usare solo per la parte smtp out con autenticazione, e provare con quello.
Comunque se già avevi in mente di usare un sistema professionale per l'invio delle newsletter, a questo punto la risposta viene da sola: usa lo stesso sistema anche per le email di conferma. Il delta di costo non può che essere irrisorio, se non addirittura zero nel nostro caso.
-
Ciao
Comprendo bene il disagio relativo alla mancata consegna e ancora di più quanto sia scocciante non riuscire a identificare con esattezza quale sia il parametro che gmail utilizza per bloccare le tue comunicazioni
Mi permetto pero' di sconsigliarti in maniera totale assoluta la disabilitazione della richiesta di conferma che ha comunque potenziali effetti "sgraditi"
Molto meglio curare la fase "PRE" iscrizione, segnalando meglio possibile cosa l'utente riceverà e come dovrà comportarsi
Concordo anche con la possibile scelta di un servizio dedicato
in bocca al lupo