Settings cheatsheet to send emails through SSL connections (for instance, gMail) with Cobian Backup

 

Mail Settings :
SMTP server : smtp.gmail.com
Port : 587
Authentication : yes + UserName/Password

Advanced settings :
Force Unicode headers : yes
Force Unicode body : yes
Use Ehlo : yes

SSL :
Transport Level Security : Explicit
SSL Method : TLS v1
Authentication type : Auto
Data port protection : Clear
SSL mode : Unassigned
Verify depth : 0

 

Source: zimmers.net

COMMODORE 64 SERVICE MANUAL

This manual is formatted with 50 lines per page. Each page break is
identified with a tilde (~) character. There is some pages that didn't fit
on the 50 line, those pages are breaked into two (or more) 50 line
sections.

Most of the figures was too complex to convert to ASCII and are identified
as [Figure: Blah blah].

Anno di uscita 1982
Processore MOS Technology 6510 : 1.023 MHz (versione NTSC) : 0.985 MHz (versione PAL)
RAM 64 Kb (38 Kb per BASIC)
ROM: 20 Kb
OS BASIC 2.0
Chipset Grafico VIC-II (Palette 16 colori, Sprite)
Risoluzione 320 x 200 - Hi-Res 160 x 200 - Multicolor
Chip Sonoro SID 6581/8580, 3 canali
Porte I/O
  • 1x Connettore per Cartuccia
  • 1x Porta Seriale (Disco Drive, stampante eccetera)
  • 2 Porte Joystick
  • 1x Connettore Audio/Video (RGB)
  • 1x RF out (Connettore Antenna TV)
  • 1x Registratore (originale Datasette)
  • 1x User Port, porta libera e programmabile Input/Output

Dopo una bella passata di Windows Update (su un fresh install di Windows Server 2008 R2), mi accorgo che da una buona mezz'ora il Server di è piantanto così:

Fase 3 di 3
Preparazione configurazione di Windows.
Non spegnere il computer.

Per scrupolo attendo un'oretta, non senza preoccuparmi già per il controller SAS, e finalmente inizio a capire che si tratta di un altro noioso BUG di Windows.

Soluzione:

si tratta di un problema noto che si verifica durante l'installazione dell'aggiornamento Microsoft KB2533552, per aggirare il problema è sufficiente premere CTRL+ALT+CANC per tornare alla schermata di login.

Microsoft raccomanda di installare l'aggiornamento separatamente.

Nota: il presente bug è presente su Windows Server 2008 R2 e su Windows 7.

Ricordo con piacere quando inviare manualmente un'email dal proprio server SMTP personale era molto semplice e straight-forward.

Era sufficiente aprire una connessione telnet verso il server di destinazione e inviare l'email. Si potevano inviare email anonime, si poteva impersonare qualsiasi indirizzo email, e tanto altro.

Se si era pigri, quasi tutti i server SMTP effettuavano volentieri il relay, rendendo l'invio di posta elettronica ancora più semplice, per tutti i tipi di utente.

Ora l'ambiente dei server SMTP è completamente cambiato. A causa dell'abuso (o meglio definirlo stupro) di tutto il meccanismo di MTA da parte degli spammers, le regole del gioco sono diventate molto più complesse e articolate. E' giusto che un server di posta come quello di Tiscali, per esempio, debba difendersi da 1 miliardo di messaggi SPAM al giorno, altrimenti il server diventerebbe inutilizzabile ma soprattutto le caselle di posta sarebbero stracolme. Ricordo infatti che, in un certo periodo, prima che le regole fossero tanto enforced, che nella mia casella di posta Tiscali arrivavano almeno 200 messaggi di SPAM al giorno. Gli ISP soffrivano molto.

Come sono cambiate le cose? Sono state apportate diverse modifiche al sistema di trasferimento posta, ma quello di cui voglio parlare in questo post sono le IP BLACKLIST. Alcuni sysadmin effettuano direttamente dal firewall, a occhi chiusi, il DROP di tutti i pacchetti in arrivo dai cosiddetti Paesi Canaglia, e cioè i TOP Spammers (ad oggi): Cina, Russia, Ucraina, Giappone, Brasile, India, Turchia.

La cosa simpatica è che gli USA sono al primo posto della classifica per l'invio dello SPAM ma non possono essere inclusi nelle country-block lists perché altrimenti si taglierebbero fuori dei giganti come Google, Yahoo, ecc. Idem per il Regno Unito e la Germania, rispettivamente al sesto e alll'ottavo posto secondo SpamHaus. Insomma: se le Cina e l'India manda SPAM la blocchiamo, chi se ne frega? Tanto chi aspetta email dalla Cina?

Io personalmente non credo che bloccare intere reti di IP appartenenti ad alcuni Paesi sia una soluzione corretta, per due motivi: il primo è che così facendo si impedisce ad un utente/cliente legittimo di accedere al servizio, il secondo è che in ogni caso, il problema non viene risolto in quanto la stragrande maggioranza dello SPAM arriva dagli Stati Uniti. Nei server che gestisco io, per esempio, la quasi totalità dello SPAM arriva da Houston, Texas. Esatto: nella mia mente, quando mi viene nominata Houston, non penso alle missioni nello spazio ma ad una bella scatoletta di poltiglia di carne.

Un altro metodo largamente utilizzato e molto efficace, è l'utilizzo delle RBL: realtime black lists. Se un determinato indirizzo IP viene segnalato come sorgente di SPAM, viene aggiunto ad un elenco che popola un database accessibile tramite query DNS (in genere il record A punta a 127.0.0.2). Fin qui tutto bene: in teoria se possiedo un indirizzo IP statico e invio SPAM vengo segnalato e non posso più nuocere a nessuno. IN TEORIA. In pratica, dentro queste liste nere, soprattutto se sono gestite male e da persone che in realtà non sono mosse da uno spirito di collaborazione ma bensì da interessi economici, finiscono spesso interi fasci di indirizzi IP che legittimamente inviano normale posta per conto dei loro clienti. Alcune RBL sono gestite molto bene e sono affidabili, come per esempio BARRACUDA e SPAMHAUS, che sono per me le più autorevoli, altre sono gestite male o hanno politiche a dir poco balzane. Secondo alcuni sarebbe corretto che si istituisse una sorta di monopolio dei server SMTP, negando a tutti il diritto di inviare posta tranne che a pochi eletti.

A proposito di questo, mi appello a tutti i sysadmin perché facciano delle serie considerazioni su quali RBL accreditare come affidabili e su quali invece evitare. Per esempio, noto con piacere che solo pochissimi utilizzano SPAMCANNIBAL, che è tristemente nota per bandire a vita interi fasci di indirizzi IP senza dare la possibilità di essere rimossi, a meno che non si sia titolari di record PTR che ormai, tra l'altro, sono considerati obsoleti. Diciamo pure che se per sbaglio un'azienda con indirizzo IP statico dovesse finire nel loro database (sovente ciò avviene anche senza alcun motivo), e poi quello stesso indirizzo IP dovesse essere assegnato, diciamo un anno dopo, ad un'altra azienda, questa nuova azienda che dovesse ereditare l'indirizzo IP non potrebbe, secondo SPAMCANNIBAL, inviare posta. Io definisco questa politica in questa maniera: DA PAZZI. Finora ho potuto verificare che fortunatamente questo database è utilizzato da pochissimi.

Veniamo ora ad un altro male del mondo: BACKSCATTERER. Questa blacklist fa semplicemente ridere, non si può prenderla seriamente.Inseriscono nei loro database indirizzi a caso bloccandoli, e poi chiedono per lo sblocco un pagamento, ad oggi di EURO 85,00. Basta fare una ricerca su internet per scoprire che chi paga non viene neanche rimosso. Eppure, esiste un (ex?) gigante che la utilizza, non per classificare la posta, ma per negare la comunicazione col proprio server: TISCALI. Proprio così, e io mi appello ai sysadmin di Tiscali perché rivedano la loro obsoleta configurazione MTA ed escludano dagli RBL lo spregevole BACKSSCATTERER (finanziato da noti personaggi truffaldini: UCEPROTECT).

Da un primo controllo sembrerebbe infatti che attualmente, l'unico provider di grandi dimensioni che utilizzi questa blacklist sia proprio Tiscali. L'unico. Non voglio dire che tutti adesso dobbiamo seguire quello che fa Google, anche se negli ultimi anni sta praticamente dettando legge e si sta infiltrando negli standard delll'intera rete globale, ma una cosa è certa: se, cari sysadmin di Tiscali, siete gli unici ad utilizzare questa RBL, un motivo deve esserci.

 

Giacomo Arru,

sysadmin BETA Technologies

ImpresaCloud

ImpresaCloud

Laboratorio di informatica e di elettronica

Cerchi informazioni sulle riparazioni in laboratorio? Hai qualche curiosità riguardo la riparazione di qualche scheda elettronica in particolare? Nella sezione Riparazioni del nostro Blog troverai moltissime informazioni utili e curiosità riguardanti il mondo dell'informatica e dell'elettronica.

 

Software gestionali

Nel nostro Blog troverai gratis tante informazioni utili riguardo i nostri software gestionali, guide passo-passo per l'utilizzo dei programmi, suggerimenti e aiuto.

 

Sistemistica informatica

Nel Blog Sistemistica troverai interessanti articoli scritti dal nostro team riguardanti il mondo di BSD, Linux, e dei Server Windows. Tutorial, best-practices, e tanto altro.

 

Notizie

Notizie interessanti riguardanti l'elettronica e l'informatica.