• User Attivo

    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).


  • User

    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.


  • User Attivo

    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.

  • User Attivo

    @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.


  • User

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


  • User Attivo

    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?


  • User

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


  • User Attivo

    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...


  • User

    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


  • User Attivo

    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.


  • User

    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?


  • User Attivo

    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?


  • User

    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.


  • User Attivo

    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)


  • User Attivo

    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.


  • User

    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.


  • User Attivo

    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.


  • User

    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.


  • User Attivo

    Quello che sia io che Nazzareno cercavamo di dire quando abbiamo detto che i filtri ti stanno trattando da spammer è che normalmente questo trattamento non viene riservato a chi configura male il mailserver ma solo a chi fa veramente molto spam e quindi non può essere solamente la conseguenza di un SPF impostato male o di un reverse che non coincide o cose simili. Per questo se la blacklist continua a presentarsi nonostante tu non invii spam c'è da capire cosa ci sia di grosso che non va. Ad esempio potrebbe essere che hai dei vicini di IP molto spammosi (ma facendo un controllo non mi sembra) o ancora che qualche spammer abbia trovato il modo di abusare del tuo server e spedisca spam a tua insaputa, e cose simili.

    Se continuano a mettere i tuoi IP in blacklist significa che ricevono un numero alto di segnalazioni di abuso in proporzione alle email inviate: se escludi categoricamente che la gente segnali abusi per le vostre newsletter allora l'unica altra possibilità è che dallo stesso IP partano altre email che la gente segnala come tali. Considera che quando richiedi un azzeramento della reputazione arrivi ad un valore che non è certamente ottimale. Una reputazione nulla è una reputazione tutta da costruire. Nessuno dice in giro male di te, ma nessuno ti conosce e quindi basta un minimo sgarro per passare a reputazione negativa. Al contrario quando sei "noto" ed hai una buona reputazione è più difficile che tu finisca in una blacklist per poche segnalazioni di abuso.

    Nonostante tutte queste considerazioni il tuo caso mostra sicuramente delle anomalie.

    Tienici aggiornati con gli sviluppi della cosa!