Problema invio mail, controlli e log

[giorgioc]

Problema invio mail, controlli e log

Ciao a tutti,
vi scrivo perchè ormai è da un pò che ho un problema abbastanza grave inerente l'invio di newsletter.
Invio per un cliente molto importante e gli invii mensili più importanti sono due di circa 300k e 200k invii.
Il tutto avviene attraverso l'utilizzo di un server in casa tramite il software Groupmail v 5.3.134.
I diversi tipi di controllo che facciamo e che comunque non risolvono i nostri problemi sono i seguenti:

• che il codice sia indentato correttamente,
• che le immagini/grafica non siano hostati su domini/ip blacklistati (con mxtoolbox),
• che non ci siano link orfani nell'html (con link examiner dopo aver pubblicato il codice),
• che il risultato dell'invio restituisca un punteggio valido (attraverso il sito mail-tester),
• che i gruppi creati all'interno di Groupmail per eventuali test interni client/mobile ricevano e visualizzino correttamente la newsletter (anche con litmus).

I diversi errori che riscontriamo li abbiamo soprattutto su:

• mondo microsoft (praticamente tutto)
  Error with sending sender
  *Server says: 421 RP-001 (SNT004-MC3F31) Unfortunately, some messages from 213.215.234.145 weren't sent. Please try again. We have limits for how many messages can be sent per hour and per day. You can also refer to *mail.live.com/mail/troubleshooting.aspx#errors.code:4 : MAIL Command Error. The Email Address you are using as your From Address (Account Manager, Properties) has been rejected by the mail server you using. Please make sure that you are using the correct identity details for this server.

tiscali
*- Error with connecting server

• socket timeout to connect etb-3.mail.tiscali.it - Please try increasing the Timeout Setting for this Account (Account Properties/Advanced)*

poste
*- Error with sending data

• Server says: 554 Message refused
• code:7 : DATA Command Error. There was an error sending data to the specified mail server. Please make sure that your internet connection is functioning correctly. If you have an Anti-Virus program running please make sure that it is configured NOT to check OUT BOUND email.*

fastwebnet
*- Error with sending data

• Server says: 554 Message refused
• code:7 : DATA Command Error. There was an error sending data to the specified mail server. Please make sure that your internet connection is functioning correctly. If you have an Anti-Virus program running please make sure that it is configured NOT to check OUT BOUND email.*

Antivirus installato: clamwin.
sono state implementati sia SPF che DKIM validi.
inoltre abbiamo contattato anche la microsoft, attraverso i loro form online.
I nostri Ip hanno ad oggi Reputation ID non negativa.
Il controllo delle blacklist avviene ogni mattina (esiste un modo automatico?).
Il metodo di invio avviene in modalità Direct (delivery Options).

Grazie mille

[bago]

Ciao Giorgio,

• ogni quanto avviene l'invio?
• fai monitoraggio di aperture/clic? quali sono mediamente?
• fai pulizia della lista? (analisi dei bounce, eliminazione delle caselle che non funzionano più o danno errori troppo spesso)
• la disiscrizione è semplice e ben evidente?
• l'ip che invia il tutto invia solo questo o altro (è quel 213.215.234.145?)?

aspetto risposte su quelle domande comunque intanto ti dico anche che:

• fastwebnet/poste: rifiutano i messaggi entranti tramite un filtro di reputazione IP o di reputazione contenuti di CloudMark: verifica se le stesse email inviate a libero finiscono in spam o in posta in arrivo (anche libero usa CloudMark ma solo la seconda parte del filtro). Se arriva in spam prendi le intestazioni dell'email libero e incollale qui.

• tiscali/hotmail (yahoo e molti altri): hanno dei limiti sul numero di connessioni/messaggi che puoi inviare in un determinato perioro di tempo. Questo limite varia in base a ciò che fai, in base alla tua storia. Se normalmente invii 1000 messaggi al giorno di buona qualità loro si aspettano quel volume, se un giorno provi ad inviare 100.000 loro si arrabbiano e cercano di limitarti. Devi cercare di mantenere costanza di volumi e contemporaneamente di mantenere buona reputazione.

• parli di reputazione "non negativa": se da quell'IP invii solo quella newsletter la reputazione deve esserre POSITIVA: reputazione neutrale per un IP che invia con poca costanza è già di per se un motivo per non vedere le proprie email recapitate (parlo delle reputazioni di senderscore e senderbase, dovresti specificare gli IP e quali servizi guardi per la reputazione). Considera inoltre che i 4 domini che citi non si appoggiano a sistemi antispam che usano la reputazione di senderbase e senderscore, quindi non c'è una relazione diretta: c'è comunque una correlazione basata sul fatto che quasi tutti i filtri antispam usano tecniche di calcolo della reputazione che bene o male usano criteri similari.

In generale consiglio sempre di rivolgersi a chi l'invio di newsletter lo fa per mestiere: ci sono un sacco di servizi di invio newsletter che hanno costi annuali che se ci fai due conti probabilmente sono molto inferiori al costo del tuo tempo per cercare di risolvere (e spesso non riuscirci) questi problemi, problemi che cambiano ogni settimana/mese perchè le tecniche antispam sono in continua evoluzione.

[giorgioc]

@bago said:

Ciao Giorgio,

• ogni quanto avviene l'invio?
• fai monitoraggio di aperture/clic? quali sono mediamente?
• fai pulizia della lista? (analisi dei bounce, eliminazione delle caselle che non funzionano più o danno errori troppo spesso)
• la disiscrizione è semplice e ben evidente?
• l'ip che invia il tutto invia solo questo o altro (è quel 213.215.234.145?)?

aspetto risposte su quelle domande comunque intanto ti dico anche che:

• fastwebnet/poste: rifiutano i messaggi entranti tramite un filtro di reputazione IP o di reputazione contenuti di CloudMark: verifica se le stesse email inviate a libero finiscono in spam o in posta in arrivo (anche libero usa CloudMark ma solo la seconda parte del filtro). Se arriva in spam prendi le intestazioni dell'email libero e incollale qui.

• tiscali/hotmail (yahoo e molti altri): hanno dei limiti sul numero di connessioni/messaggi che puoi inviare in un determinato perioro di tempo. Questo limite varia in base a ciò che fai, in base alla tua storia. Se normalmente invii 1000 messaggi al giorno di buona qualità loro si aspettano quel volume, se un giorno provi ad inviare 100.000 loro si arrabbiano e cercano di limitarti. Devi cercare di mantenere costanza di volumi e contemporaneamente di mantenere buona reputazione.

• parli di reputazione "non negativa": se da quell'IP invii solo quella newsletter la reputazione deve esserre POSITIVA: reputazione neutrale per un IP che invia con poca costanza è già di per se un motivo per non vedere le proprie email recapitate (parlo delle reputazioni di senderscore e senderbase, dovresti specificare gli IP e quali servizi guardi per la reputazione). Considera inoltre che i 4 domini che citi non si appoggiano a sistemi antispam che usano la reputazione di senderbase e senderscore, quindi non c'è una relazione diretta: c'è comunque una correlazione basata sul fatto che quasi tutti i filtri antispam usano tecniche di calcolo della reputazione che bene o male usano criteri similari.

In generale consiglio sempre di rivolgersi a chi l'invio di newsletter lo fa per mestiere: ci sono un sacco di servizi di invio newsletter che hanno costi annuali che se ci fai due conti probabilmente sono molto inferiori al costo del tuo tempo per cercare di risolvere (e spesso non riuscirci) questi problemi, problemi che cambiano ogni settimana/mese perchè le tecniche antispam sono in continua evoluzione.

Grazie mille, sto preparando una risposta esaustiva.

[giorgioc]

@bago said:

Ciao Giorgio,

• ogni quanto avviene l'invio?
• fai monitoraggio di aperture/clic? quali sono mediamente?
• fai pulizia della lista? (analisi dei bounce, eliminazione delle caselle che non funzionano più o danno errori troppo spesso)
• la disiscrizione è semplice e ben evidente?
• l'ip che invia il tutto invia solo questo o altro (è quel 213.215.234.145?)?

aspetto risposte su quelle domande comunque intanto ti dico anche che:

• fastwebnet/poste: rifiutano i messaggi entranti tramite un filtro di reputazione IP o di reputazione contenuti di CloudMark: verifica se le stesse email inviate a libero finiscono in spam o in posta in arrivo (anche libero usa CloudMark ma solo la seconda parte del filtro). Se arriva in spam prendi le intestazioni dell'email libero e incollale qui.

• tiscali/hotmail (yahoo e molti altri): hanno dei limiti sul numero di connessioni/messaggi che puoi inviare in un determinato perioro di tempo. Questo limite varia in base a ciò che fai, in base alla tua storia. Se normalmente invii 1000 messaggi al giorno di buona qualità loro si aspettano quel volume, se un giorno provi ad inviare 100.000 loro si arrabbiano e cercano di limitarti. Devi cercare di mantenere costanza di volumi e contemporaneamente di mantenere buona reputazione.

• parli di reputazione "non negativa": se da quell'IP invii solo quella newsletter la reputazione deve esserre POSITIVA: reputazione neutrale per un IP che invia con poca costanza è già di per se un motivo per non vedere le proprie email recapitate (parlo delle reputazioni di senderscore e senderbase, dovresti specificare gli IP e quali servizi guardi per la reputazione). Considera inoltre che i 4 domini che citi non si appoggiano a sistemi antispam che usano la reputazione di senderbase e senderscore, quindi non c'è una relazione diretta: c'è comunque una correlazione basata sul fatto che quasi tutti i filtri antispam usano tecniche di calcolo della reputazione che bene o male usano criteri similari.

In generale consiglio sempre di rivolgersi a chi l'invio di newsletter lo fa per mestiere: ci sono un sacco di servizi di invio newsletter che hanno costi annuali che se ci fai due conti probabilmente sono molto inferiori al costo del tuo tempo per cercare di risolvere (e spesso non riuscirci) questi problemi, problemi che cambiano ogni settimana/mese perchè le tecniche antispam sono in continua evoluzione.

Grazie mille per la tua gentile e completa risposta. Ti rispondo subito:

• L'invio delle due newsletter avviene una volta al mese.
• Facciamo il monitoraggio delle aperture/click es:
  (Totale invii / open)
  1a newsletter
  280000/95000 circa
  220000/100000 circa
  250000/95000 circa
  230000/100000 circa

2a newsletter
75000/17000 circa
77000/17000 circa
47000/15000 circa
48000/15000 circa

• Facciamo la pulizia delle liste? non lo facciamo totalmente; se si intende l?eliminazione di caselle individuate come inesistenti perché ad oggi non mi sembra sia stato mai possibile reperire tale informazione.
• La disiscrizione è semplice e ben evidente.
• Gli ip che inviano sono 3:
  213.215.234.145
  ######################
  fastwebnet/poste/libero:
  Return-Path: <#>
  X-cp3a: Suspected Spam
  Received: from libero.it (10.248.25.132) by cpms149.iol.local (8.6.138)
  id 550F57140082952E for # ; Thu, 16 Apr 2015 10:13:29 +0200
  Received: from icarus.topcs.it ([213.215.234.145])
  by smtp-04.iol.local with bizsmtp
  id GYDV1q00r38tk9x04YDVDy; Thu, 16 Apr 2015 10:13:29 +0200
  x-libjamoibt: 2601
  Received-SPF: pass
  X-Brightmail: 1.00
  X-CNFS-Analysis: v=2.1 cv=SPHMVYfH c=1 sm=1 tr=0 p=i-OMgNsdAAAA:8
  a=DJnrIKYJPy+YFWgPNzA0wA==:117 a=DJnrIKYJPy+YFWgPNzA0wA==:17
  a=e9J7MTPGsLIA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=9iDbn-4jx3cA:10
  a=cKsnjEOsciEA:10 a=gZbpxnkM3yUA:10 a=JXLSjYTZAAAA:8 a=olnOUbP2AAAA:8
  a=rgEZ65cOAAAA:8 a=wiuNjCpRRkEIK7YdzAAA:9 a=pILNOxqGKmIA:10 a=SSmOFEACAAAA:8
  a=z9rUaRY0AAAA:8 a=65dQJbl7AAAA:8 a=9yMoJGCGiE5OLlCGYwgA:9
  a=OTxE6p8vXYHa0Clh:21 a=_W_S_7VecoQA:10 a=W2FKtZq2lEYA:10 a=_v8Z66LNOQkA:10
  a=ztrUNL35uGcA:10 a=p403mkujtbAA:10
  Received: from icarus.topcs.it[127.0.0.1] by icarus.topcs.it[127.0.0.1]
  (SMTPD32); Thu, 16 Apr 2015 10:13:30 +0200
  Organization: #
  Message-ID: <150e4594c70cebf059fdc934001d84be@#>
  From: "#"<#>
  To: "=?windows-1252?Q?+.d'[email protected]?=" <#>
  Subject: #
  Date: 16-apr-2015 10.13
  MIME-Version: 1.0
  Content-Type: multipart/alternative;
  boundary="----=SPLITOR00A_001_64974681D"
  ####################
  tiscali/hotmail: purtroppo le due newsletter mensili partono verso fine mese.
  Supponendo che la lista sia da 300.000 invii e il primo invio ne spedisce 210.000, il secondo invio ne invierà altri 30.000, il terzo 10.000 e cosi via.
  Facciamo rigirare la procedura fino a che gli invii non arrivano a 0. Groupmail gestisce questo, filtrando gli indirizzi al quale hai già spedito. Quindi a quanto mi hai detto credo che questo influisca sull'invio "omogeneo" della

newsletter.
####################
grazie mille per il consiglio finale, stiamo proprio vagliando questa alternativa.
Se posso chiederti un consiglio qualità prezzo da poter vagliare?

Sender Score 96
Sender Score 87
Insufficient Email Seen (per il terzo)

[bago]

Sui numeri non mi è chiaro quanti sono i destinatari e se le aperture/clic sono intese come "totali" o come "utenti diversi che hanno aperto/cliccato almeno una volta quella specifica newsletter": sarebbe corretto ragionare su quest'ultimo numero visto che non è inusuale che qualche client di posta si inceppi e chieda migliaia di volte l'immagine di tracciamento o l'indirizzo di un link (andando ad invalidare tutte le statistiche).

Quando una casella non esiste lo capisci in due modi:

1. se durante la consegna SMTP il tuo server riceve dal server destinatario un errore sul comando RCPT/DATA e quindi il tuo server dovrebbe informarti di non aver consegnato il messaggio e dirti perchè.
2. se il messaggio è stato consegnato allora il server ricevente potrebbe invece spedirti all'indirizzo che vedi nel return-path una email chiamata "bounce" che dice perchè non ha consegnato un messaggio.

E' fondamentale analizzare entrambe le cose, che sia fatto a mano o in automatico non importa, ma se non lo fai nel giro di pochi mesi ti trovi sommerso di email che non esistono, nel giro di anni ti trovi indirizzi che diventano spamtrap e impediscono la corretta consegna di tutte le altre email (senza che sia più possibile ripulire la lista).

Dalla mia esperienza relativamente agli header che incolli la tua email era in spam di libero e viene bloccata da cloudmark per via di uno dei siti che linki nel messaggio e che secondo cloudmark sono in blacklist (non li troverai in nessuna blacklist pubblica, è cloudmark che ha delle blacklist interne).

Per capire esattamente cosa ti consiglio di provare ad inviare con gli stessi server una email completamente diversa (sempre a libero) e vedere che arrivi in posta in arrivo: se arriva in posta in arrivo confermi che non è colpa dei server o degli IP ma dei contenuti e quindi cominci a metterci alcuni dei link/testi delle newsletter che spedisci di solito e così facendo vai ad identificare qual è l'elemento che fa scatenare la classificazione come spam.

Purtroppo sulla costanza di invio non so aiutarti: 200-300.000 email inviate in un giorno quando il resto del mese non fai niente saranno sempre un problema. Se ti sposti su un servizio esterno che usa "IP condivisi" non avrai questo problema. Altrimenti dovresti valutare di spezzare la newsletter nell'arco del mese in modo da equilibrare il volume settimanale il più possibile.

Controlla gli stessi IP anche su senderbase, che ha un bacino più ampio e numeri di conseguenza più "significativi".

In generale le domande da cui partirei nella scelta di un servizio sono:

• dimensioni delle liste e frequenza di invio.
• Tempo di recapito richiesto (tipo l'invio a 200.000 entro 8 ore)
• Tipologia di destinatari (italiani? stranieri? quante lingue diverse?)
• La newsletter la componete voi o il vostro cliente? Volete dare accesso al cliente alla composizione delle newsletter o volete gestire tutto voi?
• Vi va bene un servizio con interfaccia in inglese o ne preferite uno con interfaccia in italiano?
• Volete un servizio gestito da italiani in italia o va bene anche un servizio americano?

[giorgioc]

Intanto non so come ringraziarti per la dritta circa "l'esistenza della mail",
ho fatto la prova che mi hai consigliato con libero e risolta quella, provando anche su poste e fastwebnet, la newsletter arriva correttamente.
ti giro gli errori della tipologia da te segnalatami:

1. RCPT Command Error. The current recipient was rejected by the mail server. If you know this is a good address then please make sure that you are using the proper mail server and authentication options for your current internet

connection.

2. Server says: 451 Requested action aborted: This mail account has sent too many messages in a short amount of time. Please try later - code:7 : DATA Command Error. There was an error sending data to the specified mail server.

Please make sure that your internet connection is functioning correctly. If you have an Anti-Virus program running please make sure that it is configured NOT to check OUT BOUND email.

3. Sending to: [email protected]
   Line 205570: Queued: [email protected]
   Line 205577: Failed: [email protected]

4. invio verso account Microsoft
   Failed: mailatlive.it

   • Error with sending data
   • Server says: 451 Requested action aborted: This mail account has sent too many messages in a short amount of time. Please try later.
   • code:7 : DATA Command Error. There was an error sending data to the specified mail server. Please make sure that your internet connection is functioning correctly. If you have an Anti-Virus program running please make sure that

it is configured NOT to check OUT BOUND email.

Per quanto riguarda Outlook, al momento sembrano arrivare.
Volelo chiederti:
si può risolvere il limite d'invio?
a quanto ho capito non c'è un modo per capire se si è "blacklistati" da cloudmark, vero?

Scelta del servizio:
Le liste sono da 250.000 e la frequenza di invio essendo newsletter mensili avviene negli ultimi 5 giorni del mese.
Tempistiche, diciamo 8/9 ore per il primo invio (per una newsletter), i rigiri, ovviamente chiederanno di meno a scalare.
Destinatari italiani.
La newsletter la compone un Agenzia (che ha i domini blacklistati, togliendone uno dalla dem ricevo tranquillamente su poste, fastwebnet e libero). Non vorrei dare accesso al cliente e nemmeno all'agenzia, vorremo solo che la

piattaforma si occupasse dell'invio, in quanto l'elaborazione dei link viene fatta precedentemente tramite un'applicazione sviluppata in Visual Studio da noi.
Non credo ci siano problemi nell'avere un interfaccia in inglese.
Idem per il servizio gestito in America.

Grazie per il tuo prezioso aiuto.

[bago]

Sugli errori specifici tralascio perchè ne esistono migliaia diversi e non è questo il luogo per analizzarli uno ad uno.
L'importante è che ti organizzi per riuscire ad identificare quelli che sono errori dovuti a blacklisting o problemi temporanei dei server riceventi, greylisting o altro errore che chiamiamo "temporaneo" (perchè se riprovi lo stesso invio più tardi è possibile che funzioni) da quelli che invece sono permanenti (e.g. la casella non esiste).
Devi assolutamente trovare il modo di monitorare TUTTI gli errori ma poi devi anche andare a togliere dalla tua lista le email per le quali i server ti hanno detto che la casella non esiste: i servizi di invio newsletter fanno tutto questo in automatico, altrimenti te lo devi fare a mano.. ogni server ti dice come stanno le cose a modo suo, esistono degli standard ma vengono ignorati pesantemente.

"si può risolvere il limite d'invio?"
Migliorando la qualità delle email che invii e distribuendo più equamente le email che invii.
Il limite dipende dalla "reputazione" che hai (quindi dalla qualità delle email che hai inviato) e dai tuoi volumi medi di invio.
Se invii tanta roba buona il limite si alza, se invii poca roba si abbassa, se invii roba cattiva si abbassa.

"a quanto ho capito non c'è un modo per capire se si è "blacklistati" da cloudmark, vero?"
Potrei risponderti che è possibile (io te l'ho appena detto guardando i tuoi header), ma è importante capire una cosa: cloudmark gestisce blacklisting collegati a tantissimi fattori della tua email. potrebbe decidere di blacklistarti per colpa dell'email mittente, della tua firma DKIM, di una parola che hai usato nel testo, di un sito che linki (come in questo caso), di un numero di telefono presente nell'email e tanti altri motivi.
Finisce in blacklist uno di questi indicatori perchè cloudmark ha rilevato che la maggior parte delle email che avevano quell'indicatore erano spam o considerate tali.
Quindi se io faccio spam mettendo sempre la parola XYZABC dentro alla mia email, cloudmark prima o poi deciderà di mettere in blacklisting la parola "XYZABC" e quindi chiunque invii email con quella sequenza finirà nelle sue grinfie.
Per uscire da questo blacklisting deve passare del tempo (settimane) senza che tale blacklisting venga "triggerato".
A quel punto devi capire però il problema che ti ha fatto blacklistare all'inizio: se puoi evitarlo lo eviti, se il problema è creato dalle email che mandi tu allora è un problema, perchè sarai destinato ad essere sempre blacklistato.

"i rigiri, ovviamente chiederanno di meno a scalare."
cosa vuol dire?
Invii la stessa email più volte agli stessi destinatari? Se lo fai potrebbe essere una delle cause per cui hai problemi di deliverability.
Le email si mandano una sola volta: rimandare la stessa email dopo poche ore o il giorno dopo solo perchè il giorno prima sei stato ignorato è uno degli errori più clamorosi che si possano fare.

Ogni volta che mandi una email e questa email non viene aperta, non viene cliccata, non viene tenuta da conto PERDI reputazione.
Ogni volta che mandi una email ad un indirizzo che non esiste più PERDI reputazione.
Ogni volta che un tuo destinatario cancella l'email senza aprirla PERDI reputazione
Ogni volta che un tuo destinatario marca l'email come spam PERDI reputazione.

Gli unici casi in cui guadagni reputazione sono quelli in cui l'utente apre l'email e non la cancella subito. Magari la tiene da conto, magari la clicca, la inoltra ad amici.

Capisci che è molto facile perdere reputazione e basta anche solo mandare email che vengono ignorate.

Spesso per migliorare la reputazione basta profilare meglio: invece di inviare 1 newsletter uguale per 250.000 persone se ne fanno 10 da 25.000 ma più rilevanti ciascuna per il gruppo a cui la si manda. Chiaro che bisogna aver profilato gli utenti per farlo.

[giorgioc]

Grazie ancora per le tue risposte.

Cerco di rispondere alle tue domande.
"i rigiri, ovviamente chiederanno di meno a scalare."
Significa che io creo un gruppo definitivo di 300.000 email, effettuo l'invio e Groupmail prova ad inviare a tutte le mail nella lista la newsletter.
Alcune Newsletter non arriveranno per diversi motivi: supponiamo che al primo invio ne spedisca 250.000; con rigirare intendo rispedire la newsletter a tutti quelli (i 50.000) che non l'hanno ricevuta.
Il secondo invio ne invierà altre 15.000 circa (sto sempre supponendo) e così vià. Le newsletter spedite vengono filtrate e tolte dalla lista, ma comunque a quanto mi hai fatto capire anche ripetere questa operazione, porta al blacklistaggio. Lo eviterò.

Ci sono degli strumenti free che mi puoi consigliare per il monitoraggio dei log, o qualcosa che possa essere utile ai fini dell'elaborazione/controllo?

[bago]

Purtroppo non conosco GroupMail e quindi non so dirti se quello che fai è giusto o meno.

In generale un mailserver dovrebbe riprovare in autonomia per almeno 3 giorni ad inviare una email se l'errore che riceve è temporaneo, quindi non dovrebbe essere necessario "reinviare" poichè il mailserver lo fa già da solo (per quegli errori per cui è previsto di poterlo fare), come del resto è previsto dalla RFC del protocollo SMTP (il documento che definisce lo standard del protocollo di consegna della posta elettronica).

L'importante è che non reinvii email a chi le ha ricevute e semplicemente non le ha aperte o le ha cancellate subito.

Inoltre dovresti anche evitare di reinviare email a caselle che non esistono più: la percentuale di email che invii a caselle inesistenti è un punteggio importante nel riconoscere gli spammer. Se tu riprovi tutte le caselle inesistenti 3-4 volte, di fatto triplichi/quadruplichi questa percentuale senza averne alcun beneficio. Se invece riprovi solo le mancate consegne per altri errori (e GroupMail non lo fa già da solo) allora può andare bene.

Non avendo mai usato GroupMail non so dirti quindi se sbagli o meno e non so nemmeno consigliarti strumenti per l'analisi dei suoi log.

[giorgioc]

Grazie ancora le indicazioni che mi hai dato hanno già risolto alcuni problemi di invio.