Simple Mail Transfer Protocol: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
m Bot: Aggiungo template {{interprogetto}} (FAQ) |
Funzionalità collegamenti suggeriti: 3 collegamenti inseriti. |
||
Riga 29:
La possibilità di inviare messaggi (<nowiki>RFC 2476</nowiki><ref>{{Cita web|url=https://tools.ietf.org/html/rfc2476|titolo=Message Submission|autore=Randall Gellens|sito=tools.ietf.org|lingua=en|accesso=2017-12-06}}</ref>) e [[SMTP Authentication|SMTP-AUTH]] (<nowiki>RFC 2554</nowiki><ref>{{Cita web|url=https://tools.ietf.org/html/rfc2554|titolo=RFC 2554}}</ref>) furono sviluppati nel 1998 e 1999, introducendo un nuovo trend nella consegna della email. Inizialmente, i server SMTP erano tipicamente all'interno di una organizzazione, ricevendo mail per l’organizzazione dall'esterno e consegnando messaggi dall'organizzazione per l’esterno. A causa della veloce espansione del [[World Wide Web]], i server SMTP hanno dovuto inserire regole specifiche e metodi per consegnare email ed autenticare gli utenti per prevenire abusi come consegna di mail non richieste ([[spam]]). Il lavoro sull'invio dei messaggi (<nowiki>RFC 2476</nowiki><ref name=":1" />) fu sviluppato perché i più famosi mail server spesso sovrascrivevano la mail per sistemare i problemi contenuti in essa come, per esempio, aggiungendo il nome di dominio ad un indirizzo non specificato. Questo comportamento è desiderato quando il messaggio viene corretto mentre si trova in uno stato iniziale ma pericoloso e dannoso quando il messaggio è stato generato altrove e sta per essere trasmesso. Separare mail tra consegna e trasmissione è visto come un modo per permettere ed incoraggiare il rewriting submission e bloccare il rewriting relay. Questa separazione tra consegna e trasmissione divenne velocemente la base della sicurezza mail.
Essendo nato come puro protocollo [[ASCII]] text-based 7-bit, SMTP non gestiva bene i file binari e i caratteri non utilizzati nella [[Lingua inglese|lingua Inglese]]. Standard come Multipurpose Internet Mail Extension ([[Multipurpose Internet Mail Extensions|MIME]]) furono sviluppati per codificare i file binari per il trasferimento tramite SMTP. I mail transfer agent (MTA) sviluppati dopo [[Sendmail]] tendevano ad essere implementati come [[8-bit-clean]] così da poter trasmettere qualsiasi file di testo contenente dati (in una qualsiasi codifica 8-bit ASCII-like) attraverso SMTP. Oggigiorno gli 8-bit-clean MTA tendono a supportare l’estensione [[8BITMIME]], permettendo la facile trasmissione di file binari, come avviene per file di testo. Recentemente è stata sviluppata l’estensione [[SMTPUTF8]] per permettere il supporto di testo con codifica [[UTF-8]], garantendo lo scambio di messaggi in lingue come [[Cirillico]] e [[Caratteri cinesi tradizionali|Cinese]].
Molte persone contribuirono allo sviluppo delle specifiche SMTP, tra i quali [[Jon Postel]], Eric Allman, Dave Crocker, Ned Freed, [[Randall Gellens]], [[John Klensin]] e [[Keith Moore]].
Riga 59:
Un server di trasmissione tipicamente determina quale è il server a cui si deve connettere attraverso il record MX (Mail eXchange) del [[DNS]] di ciascun dominio. Se non esiste nessun record MX, alcuni server controllano il record A. La differenza principale tra MTA e MSA consiste nel fatto che la connessione ad un MSA richiede un'[[autenticazione SMTP]]. La suddivisione tra MTA e MSA comporta diversi benefici:
* Il MSA, poiché interagisce direttamente con l'utente (attraverso il MUA), può correggere piccoli errori nel formato del messaggio (per esempio, data mancante, destinatario mancante, nome di dominio inesistente ecc). Un MTA che accetta un messaggio non può effettuare in maniera affidabile e sicura queste modifiche a qualsiasi modifica fatta dal MTA raggiunge il mittente del messaggio, dopo che il messaggio è già stato inviato.
* MSA e MTA possono avere diverse soluzioni per il blocco dello spam. La maggior parte dei MSA richiedono un'autenticazione tramite mail e [[password]] e quindi il mittente del messaggio può essere rintracciato. Questo permette al MSA di avere una politica meno stringente sullo spam. Vedi anche: [[message submission agent]].
=== Recupero Messaggi ===
Riga 208:
* RFC 3798 - Message Disposition Notification
* RFC 3834 – Recommendations for Automatic Responses to Electronic Mail
* RFC 4952 – Overview and [[Framework]] for Internationalized E-mail
* RFC 4954 – SMTP Service Extension for Authentication (rende obsoleti RFC 2554)
* RFC 5068 – E-mail Submission Operations: Access and Accountability Requirements (BCP 134)
| |||