Perché ho bisogno di un server SMTP?

Perché ho bisogno di un server SMTP intermedio per inviare la posta? Perché il mio client (Outlook, Thunderbird) non può inviare messaggi direttamente al dominio SMTP del destinatario?

Ad esempio, se devo inviare una e-mail address@example.comcon il mio account Gmail, la invio al smtp.gmail.comserver; e quindi questo server invierà il mio messaggio al server MX di example.com.

È tecnicamente possibile inviare un'e-mail direttamente al server SMTP del destinatario dal tuo computer.

Osservandolo da una base storica, se il server SMTP remoto è inattivo, si desidera che un sistema lo gestisca automaticamente e continui a riprovare, quindi si dispone di un server SMTP. Allo stesso modo, ai vecchi tempi, non tutti i server di posta erano sempre connessi: i collegamenti a lunga distanza erano costosi, quindi la posta veniva messa in coda e inviata quando veniva stabilito un collegamento.

Passando al punto in cui Internet è economico, è ancora utile disporre di meccanismi per riprovare l'invio di e-mail se un server non è disponibile e non è l'ideale per questa funzionalità essere scritta nel MUA (agente utente di posta / programma di posta dell'utente finale). Queste funzioni si adattano a un MTA (server di posta / server SMTP).

Ma peggiora: gli spammer . La maggior parte delle e-mail (ben oltre l'80%) sono spam. Quindi i fornitori di posta fanno tutto il possibile per ridurre questo problema - e un gran numero di tecniche fanno ipotesi sul modo in cui la posta elettronica viene recapitata - le seguenti sono considerazioni importanti:

1. Greylisting: alcuni provider interromperanno automaticamente una connessione di posta se il mittente e il destinatario non hanno comunicato prima e si aspettano che provino una seconda volta, perché spesso gli spammer non lo fanno, mentre si suppone sempre che un server SMTP. Ciò riduce i volumi di spam di circa l'80%. Fa schifo dover fare questo però.

2. Reputazione: è molto più probabile che qualcuno che invii e-mail attraverso un server SMTP affidabile e noto sia legittimo di un server fly-by-night. Per avere un'idea della reputazione, i provider fanno una serie di cose:

   1. Blocca indirizzi dinamici / client (non 100%, ma sono stati mappati blocchi di grandi dimensioni di Internet).

   2. Guarda che il DNS inverso corrisponde al DNS in avanti: non molto difficile da fare, ma mostra un certo livello di responsabilità e conoscenza delle migliori pratiche e qualcosa che molti blocchi di indirizzi client non hanno.

   3. Reputazione: quando comunicano con altri server SMTP, molti provider tengono traccia della quantità di spam e dei volumi di e-mail inviati e possono ridurre la quantità di spam limitando le connessioni e tenendo d'occhio questi parametri. (Esistono molti modi per farlo, non tutti ovvi, ma che richiedono un mittente noto).

   4. SPF e DKIM: questi meccanismi legano le risorse DNS al nome del dominio per rendere più difficile la contraffazione della posta e sarebbero difficili (ma non necessariamente impossibili da implementare se il programma di posta (MUA) è responsabile della posta in uscita. (Aggiunto per rendere questa risposta più completo in quanto è già stato accettato. Il merito è che dovrebbe andare ai poster sottostanti perché mi è sfuggito di mente, ma è comunque molto valido)

Probabilmente ci sono altre preoccupazioni minori, ma queste sarebbero le maggiori.

Perché ho bisogno di un server SMTP intermedio per inviare la posta? Perché il mio client (Outlook, Thunderbird) non può inviare messaggi direttamente al dominio SMTP del destinatario?

Nel 1991, e la maggior parte dei primi anni '90 e anche prima, potresti essere in grado di fare ciò che descrivi. Ma la realtà nel 2015 è che, mentre tecnicamente è possibile inviare e-mail a chiunque da qualsiasi macchina su cui sia installato un servizio di posta, il mondo di SPAM ha reso quel metodo effettivamente inutile.

Quando si utilizza un servizio SMTP "reale", le cose vengono impostate come record PTR, record SPF e persino DomainKeys che sono tutti stabiliti per un solo scopo e un solo scopo: garantire che lo SMTP che sta inviando il messaggio è legittimo. E se non lo è? Filtra il messaggio in una cartella SPAM o nel "grande abisso" della cancellazione. Ecco una ripartizione di ciò che ciascuno di questi elementi sono:

• PTR (record puntatore / record DNS inverso): verifica a livello di server. Come spiegato qui , un record PTR viene utilizzato per mappare un'interfaccia di rete (IP) su un nome host. Significa che se si dispone di un indirizzo 123.456.789.0sul server SMTP per l'invio di e-mail per smtp.example.comun record PTR appropriato per quello sarebbe smtp.example.com. Sembra troppo semplice, ma funziona dal momento che l'unico che può davvero impostare un record PTR è il proprietario dell'indirizzo IP e può essere impostato solo sul proprio hardware. Quindi funge da punto di verifica nei confronti di chi possiede / gestisce / gestisce quell'indirizzo IP.

• SPF (Sender Policy Framework): verifica del livello di entrata DNS del nome host. Un record SPF - come spiegato qui - è fondamentalmente un record DNS impostato dal titolare del nome di dominio che fornisce un elenco di indirizzi IP e nomi host di server a cui è consentito inviare e-mail per quel nome di dominio. Anche questo è un altro passaggio di verifica che garantisce che solo il vero proprietario del nome di dominio per un server SMTP possa inviare e-mail. Supponiamo quindi che un server con l'indirizzo IP di 123.456.789.9invii e-mail example.com. Sappiamo già che smtp.example.comutilizza 123.456.789.0, ma una voce del record SPF per example.compuò indicare: “Ehi! 123.456.789.9è un buon server! È legittimo! Rispetta le sue e-mail! "

• DKIM (DomainKeys Identified Mail): verifica a livello di messaggio di posta elettronica. Come spiegato qui e su Wikipedia , “DKIM è un sistema di convalida della posta elettronica progettato per rilevare lo spoofing della posta elettronica fornendo un meccanismo che consente di ricevere scambiatori di posta elettronica per verificare che la posta in arrivo da un dominio sia autorizzata dagli amministratori di quel dominio e che l'e-mail (inclusi gli allegati) non è stato modificato durante il trasporto. ”Utilizzando hash crittografici, DKIM verifica che la posta stessa non sia stata filtrata o manomessa durante il transito. Questo serve anche come ulteriore punto di verifica nella catena "Sei legittimo o sei SPAM?".

Quindi, alla fine, un server SMTP pubblico che vale qualcosa avrà almeno due di questi elementi (PTR e SPF) impostati per verificare che il server SMTP e la relativa posta elettronica siano legittimi. Non tutti usano DKIM, ma è un altro livello di convalida che sta diventando sempre più popolare oggigiorno quando gli SPAMmers diventano più tenaci nei loro sforzi per inviare SPAM.

La maggior parte degli ISP residenziali blocca la porta TCP 25 (SMTP) per impedire la partecipazione a una rete spam. Se il tuo PC viene infettato, il tuo PC può iniziare a vomitare spam per volere di qualcun altro.

Le altre risposte sono tutte eccellenti e lo spam ha molto a che fare con esso.

Ma in realtà esiste una risposta più semplice, più generica: le funzionalità. L'invio di e-mail tramite SMTP è in realtà un'impresa molto complessa. Anche senza spam, non si vorrebbe implementare l'intero set di funzionalità del protocollo SMTP in ogni client di posta elettronica; stai meglio con un software dedicato (sendmail, postfix ecc. sono i più grandi nel mondo * nix, Exchange nel mondo Windows).

Ad esempio, anche al massimo, un server SMTP "reale" deve almeno essere in grado di risolvere i record MX. Quindi deve negoziare le funzionalità (principalmente TLS, ma ci sono anche altre funzionalità). Deve gestire le code per riprovare, generare rapporti di mancato recapito, ecc.

E questa è solo la funzionalità di base, indispensabile, senza la quale il server non funzionerebbe nemmeno. Non include nemmeno cose come la riscrittura degli indirizzi, i mailertabili. Per non parlare della dozzina di altri protocolli supportati da sendmail e altri, come UUCP.

L'implementazione SMTP in Outlook, Thunderbird ecc. È molto minima - nella migliore delle ipotesi, all'incirca l'equivalente dell'utilizzo di uno smart host su sendmail, se quello.

Problema correlato, ma separato: l'e-mail è un argomento molto sensibile alla sicurezza e vorresti avere uno o pochissimi server gestiti centralmente che la gestiscono, anziché potenzialmente centinaia o migliaia di singoli su ciascun desktop.

Perché ho bisogno di un server SMTP intermedio per inviare la posta? Perché il mio client (Outlook, Thunderbird) non può inviare messaggi direttamente al dominio SMTP del destinatario?

Potresti creare un programma di posta elettronica che ha fatto questo, e non ho dubbi che anche altri lo abbiano fatto (o provato) prima.

In sostanza, dovresti scrivere uno strumento che sia sia MUA (agente utente di posta) sia MTA (agente di trasferimento posta) in uno.

Il motivo per cui questo è tradizionalmente separato in diversi strumenti, con l'MTA residente "lato server", è che un MTA che invia posta attraverso Internet aperto è considerevolmente più complesso da scrivere e configurare, e anche che trae vantaggio dal risiedere in un server "sempre attivo" affidabile.

Un MTA deve:

• Cerca e connettiti ai server di cui non si fida, o che potrebbero comportarsi in modo errato, e gestisci le condizioni di errore in un modo ragionevole che non perda la posta.

• Gestire i server inattivi e instradare verso server alternativi o mettere in coda la posta per riprovare in seguito. Funziona meglio su un processo server "sempre connesso" a Internet. Implica anche che l'agente di trasferimento della posta abbia bisogno delle proprie aree di archiviazione per la posta in coda.

• Gestire una gamma di diverse capacità del server, regolando il comportamento in base alle capacità del server ricevente.

• Segnala all'utente le condizioni di errore o la mancata consegna della posta, in modo che la posta non vada persa.

• Avere eccellenti pratiche di sicurezza ed essere molto attenti alla sicurezza.

• Idealmente, risiede su un server affidabile, sempre connesso con un indirizzo IP stabile e una voce DNS inversa, ovvero una connessione Internet adatta per server rivolti al pubblico. Questo aiuta altri sistemi a non rilevare la posta inviata come spam.

Dati questi requisiti ha senso alloggiare il server SMTP su un server sempre attivo pubblico da qualche parte e provare a utilizzare uno strumento adatto a svolgere quel particolare lavoro.

Un'altra cosa da considerare è ricevere email restituite . Come minimo, tutte le e-mail in uscita hanno un indirizzo FROM a cui è possibile inviare una risposta (utente sconosciuto, risposta ferie, ecc.). Affinché l'indirizzo di ritorno si risolva, deve esistere un record MX che punti alla posizione della posta in arrivo di ritorno. A meno che non si invii e-mail da un computer con un indirizzo IP statico sempre attivo, sarà necessario un server per gestire questi messaggi in entrata. Questo è generalmente (ma non sempre) gestito dallo stesso servizio.

GMail, Outlook 365 e Yahoo Mail sono esempi di servizi di posta elettronica che vengono utilizzati dalle persone che inviano e-mail. Per l'invio di e-mail commerciali, ci sono servizi come MailChimp, Marketo ed Eloqua che sono molto bravi nell'invio di e-mail di massa per un'azienda e nella gestione di cose come rimbalzi, limitazione e consegna.

Vedi: https://en.m.wikipedia.org/wiki/Bounce_address