5
W teorii zestaw Żądania Komentarze (RFC) zawiera wszystko, co programista musi wiedzieć, aby zbudować klienta SMTP. Jednak nie zawsze łatwo jest ustalić, które RFC należy rozważyć, a które można zignorować.Jakie RFC należy uwzględnić przy tworzeniu klienta SMTP?
Czy ktoś ma plan działania RFC, aby sterować programistami? Przez mapę drogową RFC, to znaczy:
- Pełną listę RFC, które muszą być odczytywane w celu rozwijać klienta SMTP.
- Wskazanie, które dokumenty RFC nie są już potrzebne, ponieważ zostały zastąpione.
- Podsumowanie odpowiednich dokumentów RFC.
- Szczegóły na temat wzajemnego powiązania odpowiednich specyfikacji RFC .
- Wskazanie logicznej kolejności do przeczytać i zrozumieć odpowiednie specyfikacje RFC .
Właśnie dlatego zadałem to pytanie. Zbyt łatwo jest skupić się na RFC, ale później okazuje się, że większość lub całość została zastąpiona przez inne RFC. Oczywiście pojawia się problem opóźnienia, gdy serwery SMTP implementują specyfikacje RFC. Z powodu opóźnień w implementacji czasami trzeba nie zapomnieć o tym, co zawiera stary dokument RFC, mimo że w warunkach ustawień standardów zostały one zastąpione. –
Korzyścią jest to, że te nowe dokumenty RFC wyjaśniają stary język i są bardziej kompletne. Ponieważ budujesz tylko klienta SMTP, a nie silnik spamu lub MTA, powinno to być prawie wszystko, czego potrzebujesz. Staje się to o wiele bardziej skomplikowane, jeśli Twój tekst mówi o MTA lub silniku spamu. Podczas gdy wiele technik anit-spamu jest publicznych, wiele z nich nie jest – LamonteCristo
Nowe wersje również ogólnie opisują, co się zmieniło i jak (jeśli w ogóle) powinieneś się dostosować. Gdy stary dokument RFC zostanie usunięty, powinno być całkiem bezpiecznie, aby trzymać się nowego. – tripleee