[Attenzione la soluzione riportata in questo articolo è valida esclusivamente per i server che ricevono la posta direttamente. Nel caso si riceva tramite Multipop o DomainPop è un problema che deve risolvere il vostro provider]
Test inoltro consentito
Fate questo test con il vostro mail server:
Da un prompt dei comandi di Windows, effettuate una sessione Telnet verso il vostro MDaemon, spacciandovi, durante la sessione SMTP, per un account locale esistente (nell'esempio info@bb.achab.it) e provando ad inviare ad un account locale o ad un indirizzo esterno. Se MDaemon lascia effettuare questo invio, come nell'esempio, il mail server è esposto a due gravi problemi:
- Ricevere lo spam "autogenerato" (SPAM inviato ad account locali a nome di altri account locali, paradossalmente, da se stessi).
- Diventare uno zombie per lo SPAM inviato ad altri domini, con il rischio di far finire il mail server stesso in black list.
Soluzione:
Il primo passo per ovviare a questo problema è richiedere a chiunque (anche l'amministratore delegato) voglia spedire attraverso il mail server di autenticarsi prima di inviare il messaggio. Per rendere obbligatoria questa autenticazione occorre andare nel menu Sicurezza > Impostazioni di sicurezza > Autenticazione mittente > Autenticazione SMTP e configurare la sezione come evidenziato nella figura che segue:
Nota
Prima di attivare l'autenticazione obbligatoria occorrerebbe verificare che:
- Non ci siano client che inviano senza autenticarsi.
- Non ci siano applicazioni automatiche che inviano senza autenticarsi.
- I client non inviino con un SMTP diversi da quello di MDaemon.
Attenzione:
L'impostazione relativa all'autenticazione potrebbe scatenare un potenziale problema e precisamente si potrebbe verificare quando utenti di Mdaemon spediscono posta tramite SMTP diversi dal server su cui sono configurati.
In questo caso, con l'opzione di autenticazione attiva tutte le mail inviate tramite l'SMTP "alieno" a utenti locali su MDaemon verrebbero rifiutate.
Un esempio tipico sono coloro che usano l'SMTP dell'ISP perché quest'ultimo blocca la porta 25 (per esempio Tele2 e 3 su tutte le connessioni mobili).
Ci possono essere anche situazioni più subdole: la maggior parte dei fornitori di accesso wifi via hot spot, ad esempio, hanno un proxy automatico sulla porta 25 che reindirizza la posta sui loro relay senza che l'utente se ne accorga.
Considerando che questo tipo di connessione è lo standard in molti alberghi, il rischio di mail rifiutate può essere non trascurabile, tanto più che questi proxy automatici spesso non restituiscono correttamente all'utente eventuali messaggi di errore.
In casi come questi si può ricorrere alla porta MSA o al sempre valido WorldClient.
Secondo test
Configurato MDaemon come da test precedente, procedete con questa altra prova:
Da un prompt dei comandi di Windows, effettuate una sessione Telnet verso il vostro MDaemon, spacciandovi questa volta, durante la sessione SMTP, per un account esterno in modo da poter fare una sessione SMTP non autenticata, ma dichiarando nell'header del messaggio (dopo il comando DATA) un mittente locale. Se MDaemon accetta questa consegna, come nell'esempio, il mail server è esposto a questa forma di SPAM.
Per ovviare a questo problema, si può ricorrere allo Scudo IP (Sicurezza > Impostazioni di sicurezza > Scudo IP):
- Abilitare il modulo.
- Inserire il proprio dominio della lista dei domini validi.
- Abilitare l'opzione "Non applicare scudo IP a sessioni autenticate" per consentire anche agli account locali, legittimi, di spedire da qualsiasi IP (se si autenticano).
- Abilitare l'opzione "Verifica l'indirizzo intestazione DA rispetto allo schermo IP" per far si che il filtro antispam consideri anche l'header del messaggio vero e proprio.
