Ti mando via messaggio privato un header completo (se lo permette, qui mi vietava di mettere indirizzi e www).

Sorry non avevo visto che erano due messaggi da parte tua.
Per l'Ip ok mi fermo
Per il sistema di invio, anche prima era Interspire, sono solo cambiati i server di uscita della posta! E non è cambiato il modo di fare la DEM (sia per codice e embed) anche prima c'era Interspire.
Solo server di invio cambiato e quindi header e cose varie! Addirittura prima non c'erano i DKIM e SPF ora si! (che passano correttamente)

A breve ti mando l'header

Da quanto tempo usate il nuovo sistema? GLi IP necessitano di un warmup, se avete fatto solo qualche invio per 1-2 settimane non mi preoccuperei e mi aspetterei una soluzione automatica nel giro di altre 1-2 settimane al massimo.

Su DKIM e SPF non sono automaticamente una cosa positiva. Intanto devono essere configurati correttamente, e poi aiutano solo ad identificare meglio chi sei e quindi a gestire anche una reputazione in maniera più corretta: per intenderci se fai SPAM avere DKIM e SPF serve solo ad aiutare i destinatari a classificarti come spammer.

Primo sull'SPF di invio-campagne-dem com hai un include dell'SPF camicieuomo it che riporta un record errato (non finisce con un -all/~all)
Secondo, sul record DKIM che pubblichi c'è "t=y" che significa che la firma DKIM deve essere ignorata.

Al momento quindi i server riceventi dovrebbero ignorare sia il tuo SPF che il tuo DKIM e dovrebbe essere tutto equivalente a non averli: questo almeno secondo le specifiche. C'è però qualche server che considera negativamente questi fattori (più che altro per ignoranza dei postmaster che non sanno che queste casistiche devono essere trattate come "neutrali" e non come negative).

Il sistema sta su da 2 settimana ormai e mandiamo 5 giorni su 7 :-)!
Ieri abbiamo messo il -all sul SPF magari ancora non si è propagato!
Ora elimino dal dns il t=y perchè se come dici te allora lo leggevano lo passavano ma lo ignoravano poi!
Per ora i record aggiornati sono questi:
"v=spf1 a ip4:95.211.176.189 ip4:95.211.176.190 ip4:95.211.176.191 ip4:95.211.176.192 ip4:95.211.176.193 include:camicieuomo.it -all"
"v=DKIM1; k=rsa; p=QUI C'E' LA CHIAVE DKIM"

Ma la specifica dell'RFC dice di metterlo il t=y però o sbaglio?
Ps hai nell'indirizzo e-mail che mi hai dato gli header chiesti.

L'SPF al quale mi riferivo io è quello "incluso":

host -t txt camicieuomo.it ns1.leaseweb.nl

camicieuomo.it descriptive text "v=spf1 ip4:95.211.176.189 ip4:95.211.176.190 ip4:95.211.176.191 ip4:95.211.176.192 ip4:95.211.176.193"
(non è una questione di propagazione perchè sto interrogando il nameserver autoritativo)

Come vedi non ha il "meccanismo" di default (-all ad esempio) alla fine. Non è obbligatorio, ma se non ce l'hai riporti sempre "Neutral".

Ora è passato parecchio tempo da quando ho implementato le specifiche SPF ma se ricordo bene se il record riferito ad un "include" ritorna neutral allora viene considerato permerror e quindi la regola originale del dominio "includente" fallisce.
Da http://www.openspf.org/SPF_Record_Syntax

The specified domain is searched for a match. If the lookup does not return a match or an error, processing proceeds to the next directive. Warning: If the domain does not have a valid SPF record, the result is a permanent error. Some mail receivers will reject based on a PermError..

Quindi

1. metti un ~all in fondo a quella regola
2. inutile che il primo dominio faccia "include:camicieuomo.it" visto che poi ripete gli stessi IP di camicieuomo.it. Quindi o lasci solo gli IP e togli l'include o lasci solo l'include e togli l'elenco di IP.

@eliofilo said:

Ma la specifica dell'RFC dice di metterlo il t=y però o sbaglio?

Dice di metterlo se vuoi testarlo senza usarlo.

http://www.ietf.org/rfc/rfc4871.txt

t= y This domain is testing DKIM. Verifiers MUST NOT treat messages from signers in testing mode differently from unsigned email, even should the signature fail to verify. Verifiers MAY wish to track testing mode results to assist the signer.

OK corretto, però credo ti conveniva fare # host -t txt invio-campagne-dem.com ns1.leaseweb.nl che è il dominio del FROM, ecc...

Comunque prima di procedere con le analisi aspetta si sia propagato il DNS. Adesso c'è in giro la configurazione che ho trovato io, e quella fa fallire l'SPF.

Inoltre nel return-path hai un no-reply, cosa sbagliatissima. Come fai a ricevere i bounce e mantenere pulita la lista?

In verità quell'indirizzo newsletter-no-reply funziona ed è reale!

Allora chiamalo diversamente! alcun filtri antispam cercano proprio la sequenza no-reply/noreply e la penalizzano. Con tutti i nomi che potevi dargli proprio uno penalizzante?
Tra l'altro il return-path non viene fatto vedere praticamente da nessun client, quindi non puoi nemmeno aver avuto motivazioni "estetiche", che comunque sarebbero state discutibili perchè è sempre meglio incentivare il "reply" e non disincentivarlo.. oggi giorno ancora di più considerando che molti provider basano la reputazione sull'engagement e il fatto che ci sia un dialogo (botta/risposta) è considerato molto positivo...

Ok ora tutte le cose principali dovrebbero esser chiare:

• DKIM e SPF sistemati e si staranno propagando.
• l'indirizzo di from e return-path corretti
• ho fatto anche una prova eliminando allegati e immagini in embed ma non è cambiato nulla.

L'unica prova da fare è capire se c'è qualcosa che non va nell'header, soprattutto per l'Unknown sull'HELO. E se mettendo un solo ip di uscita (uno tra quelli che già utilizzo) migliora le cose.

PEr gli header che ho inviato c'è qualche dubbio o consiglio?

grazie

Aspettiamo qualche giorno, prima di approfondire. Potrebbe essere sufficiente quello che hai fatto.
Altrimenti, prima di lavorare sugli header bisognerebbe provare a fare le connessioni SMTP "manuali" come ti spiegavo prima, così puoi provare a togliere header e modificare il messaggio in vari modi e vedere se qualche operazione risolve il problema o meno. A memoria non ricordo di aver visto problemi con un header "unknown", e in ogni caso l'unico server che ricordo che fa sicuramente dei check sui received è google. Poi è vero che queste cose cambiano molto frequentemente e quindi, aspettiamo qualche giorno e poi al limite proseguiamo con le ipotesi.

Aggiorno la situazione a oggi,
DKIM, SPF eccc sono configurati e passati bene. Il problema è Cloiudmark e Brightmail... i loro servizi metto i miei ip in blacklist (quindi libero, tiscali, aruba e chi usa quel servizio ne risentono)
Ho contattato nuovamente contattato Cloudmark (sarà al 5 volta che mi levano e mettono dalla lista) dicendomi che resettano e che non sarà in blacklist. Ora sembra che cloudmark non mi ha reinserito...Ho anche inviato i falsi positivi!
Per Brightmail ho inviato i falsi positivi alle mail che loro segnalano sul sito ([email protected]). Ma on ho avuto nessuna risposta.

Altra domanda libero da questo messaggio nell'header, ti che tipo di servizio anti spam si tratta?:
X-Junkmail: UCE(300)
X-Junkmail-Status: score=300/55, host=hostlibero
X-Junkmail-Signature-Raw: score=confirmed,
refid=str=0001.0A0C0208.50C74336.016A,ss=4,re=0.000,fgs=12,
ip=95.211.176.193,
so=2011-06-21 16:49:39,
dmn=2011-06-08 23:29:05,
mode=multiengine
X-Junkmail-IWF: false
X-libjamoibt: 2587
X-cp3a: Confirmed Spam

Consigli o metodi più efficaci per aggirare questi problemi?

A me alcuni sembrano gli header di Memova di CriticalPath (fornitori di Libero, Tiscali, Alice..), altri del Razorgate di Mirapoint

Comunque il prossimo step è provare a inviare la stessa email con altri IP ed email diverse con gli stessi IP per capire se c'è un problema di IP o di contenuti.

Quando parli di rimozione su cloudmark parli di dominio o IP? Il fatto che ti delistino e poi ci rifinisci è sospetto e normalmente significa che molta gente che riceve le tue newsletter ti marca come spam. Sei proprio sicuro al 100% che la lista sia opt-in e che invii alle stesse persone alle quale inviavanoi i vecchi server che non avevano problemi di delivery? Alternativamente: sei sicuro che non ci siano spammer che stanno usando i tuoi server per inviare spam a tua insaputa?

Questi invece sembrano header di Razorgate:

X-Junkmail: UCE(300)
X-Junkmail-Status: score=300/55, host=hostlibero

300 è il massimo score spam che può registrare quel sistema, e normalmente assegnato solamente a virus, malware ed email di "enlargement" di quello che puoi immaginare e cose simili: è MOLTO strano che trovi questi header in una email legittima.

Poi non ho capito una cosa: questo "X-Junkmail: UCE(300)" te lo trovi guardando gli header nella email ricevuta di libero nella casella spam o sono in un bounce ricevuto da libero?

Il "X-Junkmail: UCE(300)" lo trovo nell'header della mail che ricevo nella casella di libero (email di test e controllo)
Le liste di invio sono le stesse e vengono pulite ogni giorno da hard bounce, il vecchio server di invio era di proprietà del provider (quindi sicuramente non cosi facile da inserire in qualche backlist) ma come hai visto gli header del vecchio server erano davvero molto scarne e senza DKIM e SPF.
Inoltre non ho spammer che inviamo dai miei server al 100%.

Cludmark mi ha resettato per l'ennesima volta gli IP che uso e gli ho inviato anche il nome del dominio! ma credo abbiamo resettato entrambi, dal loro modulo di reset non risulto oggi.

Secondo me stiamo parlando troppo

Qualche messaggio fa ti ho spiegato come simulare una connessione SMTP completa con un telnet.
Prova a mandare un semplice messaggio così costruito a libero e vedi se ti arriva in spam o meno e quali sono gli header.

Questo è quello che scrivi dopo il DATA

Subject: Prova invio
From: "Tuo Nome" untuoindirizzochenonsiaquello@cheusinelleemailproblematiche
To: "Nome Destinatario" [email protected]

Semplice messaggio di testo
.

(quella riga con solo il punto è importante e serve per dire che hai finito il messaggio)

Temo che il problema sia a monte. Un azienda normale che spedisce con propri server e con i propri IP può facilmente vedere qualche messaggio che finisce nel junk, capita. Non è invece assolutamente normale essere ripetutamente inseriti nelle blacklist di N sistemi antispam. Secondo me il tuo problema principale è nella tua lista e nelle tue modalità di acquisizione, non nel tuo server di invio email.

La nostra lista di acquisizione è solo di indirizzi email acquisti via ordini web/telefonici e registrazione via sito web. Non li abbiamo certo rubati e/o presi facendo giretti strani.
Il fatto è che prima del nuovo sistema Cloudmark e affini non ci inserivano dentro i loro sistemi. Sennò ce ne saremmo già accorti visto che c'è stato un calo massiccio di letture, di ordini e soprattutto nelle nostre mail di controllo e verifica che abbiamo nei vari provider (tiscali, gmail, libero, ecc...) hanno smesso di arrivare da un giorno all'altro.

Comunque concordo con Nazzareno, i filtri ti stanno trattando da spammer e quindi se non lo sei bisogna capire quale tuo comportamento li convince di agire in questo modo. Se sei spammer non c'è una soluzione al problema, se non lo sei il primo step è capire se il problema sta nel contenuto o nell'IP e per verificarlo bisogna mandare la stessa email con un altro IP ed una email completamente "semplice" e con mittenti/domini diversi dallo stesso IP... con il risultato di questo step si decide lo step successivo.

spammer non lo siamo di sicuro, sennò mandavamo più mail non certo 10000/15000 sempre ai nostri clienti, aggiungendo quelli che si iscrivono day by day.
Se eravamo spammer sarebbero risultati i nostri IP/domini anche in altri servizi più "trasparenti" (mxtoolbox e affini) di verifica per le blacklist...
Comunque domani cercherò di fare ulteriori prove (se Cloudmark o affini mi ribloccano) e cerco di capire cosa da fastidio a Spamassassin di affini nel testo/link/ecc.. del messaggio.
Farò anche qualche prova con telnet e cose varie.