5
In teoria, l'insieme di Request For Comments (RFC) contiene tutto ciò che uno sviluppatore deve sapere per creare un client SMTP. Tuttavia, non è sempre facile sapere quali RFC devono essere considerati e quali possono essere ignorati.Quali RFC devono essere considerati nello sviluppo di un client SMTP?
Qualcuno ha una tabella di marcia RFC per guidare gli sviluppatori attraverso questo? Con RFC tabella di marcia, voglio dire:
- Un elenco completo dei RFC che hanno bisogno di essere letto e compreso, al fine di sviluppare un client SMTP.
- Un'indicazione di quali RFC non è più necessario , perché sono stati sostituiti da .
- Un riepilogo delle RFC rilevanti.
- Dettagli su come gli RFC rilevanti interagiscono tra loro.
- Un'indicazione dell'ordine logico su legge e comprende le relative RFC .
Ecco perché ho fatto la domanda. È fin troppo facile concentrarsi su un RFC, solo per scoprire successivamente che la maggior parte o la totalità di essa è stata sostituita da un'altra RFC. Poi, naturalmente, c'è il problema del ritardo, quando i server SMTP implementano gli RFC. A causa di questo ritardo di implementazione, a volte è necessario non dimenticare ciò che è contenuto nelle vecchie RFC, anche se, in termini di impostazioni degli standard, sono state sostituite. –
Il vantaggio è che queste nuove RFC chiariscono la vecchia lingua e sono più complete. Dato che stai solo costruendo un client SMTP, non un motore di spam, o MTA, questo dovrebbe essere tutto ciò di cui hai bisogno. Questo diventa molto più complicato se la tua scrittura dice un MTA o un motore di spam. Mentre molte tecniche anit-spam sono pubbliche, molte non sono le – LamonteCristo
Le nuove versioni delineano anche in generale cosa è cambiato e come (se non del tutto) dovresti adattarti. Una volta che una vecchia RFC è stata obsoleta, dovrebbe essere abbastanza sicuro attenersi a quella nuova. – tripleee