Skip to main content

Linux – Come inviare E-Mail con sSMTP (con configurazioni-tipo per GMail, Aruba e Yahoo)

Se siete capitati su questo articolo vuol dire che avete bisogno di inviare e-mail dal vostro server Linux e state cercando un’alternativa più semplice da configurare rispetto ai classici server di posta veri e propri Sendmail e Postfix. Si tratta di un’esigenza piuttosto comune, tipica di chi amministra siti e servizi in PHP e ha quindi bisogno di poter impostare il valore della proprietà sendmail_path  nel file php.ini.

L’alternativa in questione si chiama sSMTP ed è un MTA (Mail Transfer Agent) minimale che può essere utilizzato per inviare la posta in uscita dal proprio sistema Linux verso un qualsiasi mail hub. Vediamo come fare per installarlo e utilizzarlo nel modo corretto con i principali servizi SMTP di invio mail utilizzati in Italia, ovvero GMail e Aruba. I passaggi indicati sono validi per una distribuzione RedHat / CentOS7 / Fedora, ma possono essere utilizzati su qualsiasi altra distribuzione Linux senza alcun problema.

Approfondisci

ASP.NET Core: Cloud-ready, Enterprise Web Application Development – Il Libro

Sia pure con un ritardo di alcune settimane per ragioni di distribuzione è finalmente disponibile l’edizione Learning Paths del mio libro dedicato allo sviluppo di applicazioni web con ASP.NET Core e Angular: il titolo è ASP.NET Core: Cloud-ready, Enterprise Web Application Development e si inserisce nella collana dell’editore britannico Packt Publishing dedicata a corsi avanzati di sviluppo software strutturati attraverso percorsi di apprendimento che prevedono l’utilizzo combinato di diverse tecnologie.

Inutile dire che il libro in questione riguarda lo sviluppo full-stack di applicazioni web con ASP.NET Core MVC e Angular, attraverso un percorso che ha inizio con la creazione del progetto, prosegue con le interazioni client-server e si conclude con un approfondimento delle varie tecniche e strategie di ottimizzazione e performance-monitoring prima e dopo il deploy.

Questa è la versione definitiva della copertina:

Approfondisci

ASP.NET e IIS – Errore (413) Request Entity Too Large e Maximum Request Length Exceeded – Come risolvere

Se vi siete imbattuti in questo articolo è probabile che stiate cercando di configurare la vostra applicazione ASP.NET (Core, MVC, Web API, Windows Forms, WCF o altro) su un web server IIS il quale, a differenza del web server di sviluppo, si rifiuta di accettare l’upload di un file di dimensioni superiori a 16kb, restituendo uno dei seguenti errori:

(413) Request Entity Too Large

Entità richiesta troppo grande

Maximum request length exceeded

Superata la lunghezza massima della richiesta

Tutti questi errori sono relativi al superamento delle dimensioni massime di un allegato – o meglio, della Request HTTP inviata al server – previste dalla nostra applicazione ASP.NET per impostazione predefinita. Queste limitazioni sono state inserite per una valida ragione: la ricezione di un file è una operazione piuttosto pesante per il server, in quanto impegna a tempo indeterminato un working thread. Per questo motivo, le impostazioni predefinite della maggior parte delle applicazioni ASP.NET prevedono una dimensione generalmente compresa tra i 16k e i 64k, sufficiente per l’invio/ricezione di form di testo ma logicamente del tutto inadeguate quando si ha l’esigenza di gestire l’upload di uno o più file.

Approfondisci

Come bloccare l’accesso a file e cartelle condivise in LAN a uno o più indirizzi IP con Windows

Quella di bloccare l’accesso a file e/o cartelle condivise in rete a uno o più client è un’esigenza piuttosto comune. Le ragioni dietro a questa necessità possono essere varie: aumentare la sicurezza del network, semplificare l’esperienza utente di un operatore particolarmente inesperto, e così via. In ogni caso, discriminare gli accessi sulla base dell’indirizzo IP del client non è quasi mai la scelta migliore. Il Security Model di Windows è da sempre basato sull’autenticazione e autorizzazione dei singoli account, non sugli indirizzi IP. Il motivo principale alla base di questa scelta è dovuto al fatto che l’IP non fornisce sufficienti garanzie di sicurezza, in quanto può essere facilmente alterato – soprattutto in una LAN. Per questo, se vogliamo restringere l’accesso al solo personale autorizzato, la cosa migliore che possiamo fare è utilizzare la ACL di sistema mediante la consueta tab Security contenuta nella finestra pop-up accessibile tramite tasto destro > Proprietà su ogni file e/o cartella da condividere.

Nonostante questo, esistono alcuni casi-limite in cui può avere senso ricorrere a una identificazione basata sull’un indirizzo IP. In questi casi è possibile operare aggiungendo delle regole al Firewall di Windows integrato, o a qualsiasi altro software firewall installato al suo posto, per bloccare l’accesso alle porte TCP utilizzate dalle connessioni SMB-in e/o SMB-out. Per chi non lo sapesse SMB è l’acronimo di Server Message Block, il protocollo di condivisione file e stampanti utilizzato dai sistemi Windows.

Il blocco delle porte può avvenire tramite il firewall installato sui singoli client, assumendo che l’utente oggetto di questa esclusione non abbia le credenziali per poter disabilitare la regola o l’intero firewall, oppure mediante quello installato sulla macchina (o sulle macchine) dove si trovano i file e/o le cartelle condivise che vogliamo bloccare. Come sempre, la scelta migliore è data dallo scenario che ci troviamo ad affrontare: nel caso in cui dobbiamo bloccare gli accessi di una singola macchina a uno o più server può essere consigliabile operare sul firewall del client: al contrario, se dobbiamo bloccare gli accessi di un cospicuo numero di client a un singolo server, agire sul firewall di quest’ultimo potrebbe senz’altro essere la mossa più efficiente.

Approfondisci

Password MySQL scaduta: come risolvere in modo permanente

Se vi siete imbattuti in questo articolo è molto probabile che abbiate scoperto a vostre spese la nuova funzionalità introdotta con MySQL 5.7.4 e destinata probabilmente ad essere presente in tutte le versioni successive: la scadenza automatica delle password di tutti gli account, ivi compresi quelli di amministrazione e di sistema come il classico “root”. Se siete soliti connettervi manualmente al Database è probabile che abbiate ricevuto il seguente messaggio direttamente dalla GUI del vostro client MySQL preferito (SQLyog, MySQL Workbench o qualsiasi altro):

Your password has expired. To log in you must change it using a client that supports expired passwords.

Tuttavia, i primi ad accorgersi – si fa per dire – di questo problema sono spesso i siti e servizi web come Wordrpress, Joomla, phpBB e/o qualsiasi altro che necessiti di una connesione al nostro database MySQL per funzionare. Questo significa inevitabilmente accusare un downtime che, se non si interviene prontamente, può costare caro alla nostra media di uptime mensile e farci perdere più di qualche accesso.

Come sempre, la prima cosa da fare per risolvere il problema è documentarsi: la nuova funzionalità, introdotta per ovvi motivi di sicurezza, è ampiamente illustrata nella documentazione ufficiale di MySQL 5.7, che è opportuno leggere con attenzione prima di effettuare qualsiasi cambiamento.

Immediatamente dopo, possiamo passare all’azione. La scelta, che dobbiamo effettuare responsabilmente sulla base di quanto appreso dalla documentazione ufficiale, è se limitarsi a cambiare password ai nostri account MySQL – abituandoci a farlo spesso e di frequente – oppure disattivare la scadenza automatica. Inutile dire che non c’è una scelta migliore o peggiore, tutto dipende dal nostro scenario di impiego. E’ probabile che, come spesso accade in questi casi, la verità si trovi nel mezzo: nel caso in cui l’account MySQL è relativo a un operatore o amministratore, è senz’altro preferibile lasciare che la password scada periodicamente, così da essere “costretti” a cambiarla di frequente: un’ottima abitudine per ridurre al minimo i rischi legati a possibili perdite o furti di password (da parte nostra o dei nostri collaboratori) e, di conseguenza, possibili accessi non autorizzati. Al tempo stesso, se l’account è di sistema – ad esempio quello utilizzato da un sito o servizio web – è probabile che la scelta più logica sia quella di disattivare la scadenza automatica, magari limitando con l’occasione i permessi di tale account.

Cosa fare nel caso degli account utilizzato sia da servizi di sistema che da operatori? La risposta è molto semplice: è la buona occasione per liberarci definitivamente da questo tipo di account, che non dovrebbero esistere in un sistema organizzato secondo il buon senso: nessun account di sistema dovrebbe essere utilizzato anche per effettuare un accesso mauale e viceversa, secondo il ben noto principio della Separation of Duties. Potremmo dire che uno dei meriti principali di questa nuova funzionalità di MySQL è proprio quello di costringere tutti gli amministratori di sistema a rivedere la logica alla base degli account creati, facendo chiarezza una volta per tutte sul ruolo attribuito a ciascuno di essi e limitandone lo scope di conseguenza.

Tutto ciò premesso, vediamo come possiamo intervenire per risolvere il nostro problema. Nel caso in cui fossimo ancora in grado di accedere con un account con privigilegi di amministratore – come ad esempio l’account root – la soluzione sarebbe fin troppo ovvia: basterebbe effettuare il login con l’account in questione e cambiare la password scaduta. Esistono però almeno due situazioni che richiedono l’esecuzione di azioni diverse e/o aggiuntive:

 

  • Se anche la nostra password di amministrazione / root è scaduta.
  • Se vogliamo disabilitare la scadenza della password per uno o più account.

Lo scopo di questo articolo è quello di fornire tutte le informazioni necessarie per il conseguimento di questi risultati.

Approfondisci

Close