Какие RFC необходимо учитывать при разработке SMTP-клиента?

Теоретически набор запросов на комментарии (RFC) содержит все, что необходимо знать разработчику для создания SMTP-клиента. Однако не всегда легко понять, какие RFC следует учитывать, а какие можно игнорировать.

У кого-нибудь есть дорожная карта RFC, чтобы помочь разработчикам пройти через это? Под дорожной картой RFC я имею в виду:

  • Полный список RFC, которые необходимо прочитать и понять для разработки SMTP-клиента.
  • Указание того, какие RFC больше не нужно рассматривать, поскольку они были заменены.
  • Краткое изложение соответствующих RFC.
  • Подробно о том, как соответствующие RFC взаимодействуют друг с другом.
  • Указание логического порядка чтения и понимания соответствующих RFC.

smtp rfc
person Mike Green    schedule 05.02.2011    source источник

Ответы (2)


arrow_upward
4
arrow_downward

статья Википедии содержит хороший список связанных RFC.

person Martin v. Löwis    schedule 05.02.2011

arrow_upward
2
arrow_downward

Сначала вам следует прочитать RFC 5321, а затем RFC 5322... при условии, что вы уже знаете, как обрабатывать DNS-запросы.

Старый ответ раньше читался 2821, затем 2822... но, похоже, он был обновлен.

person halfbit    schedule 05.02.2011
comment
Собственно поэтому я и задал вопрос. Слишком легко сосредоточиться на RFC, а потом обнаружить, что большая часть или все его части были заменены другим RFC. Затем, конечно, возникает проблема задержки, когда SMTP-серверы реализуют RFC. Из-за этого отставания в реализации иногда необходимо не забывать, что содержится в старых RFC, хотя с точки зрения настроек стандартов они были заменены. - person Mike Green; 06.02.2011
comment
Преимущество заключается в том, что эти новые RFC разъясняют старый язык и являются более полными. Поскольку вы создаете только SMTP-клиент, а не спам-движок или MTA, этого должно быть почти все, что вам нужно. Это становится намного сложнее, если вы пишете, что это MTA или спам-движок. Хотя многие методы борьбы со спамом общедоступны, многие из них не - person halfbit; 06.02.2011
comment
В новых версиях также обычно указывается, что изменилось и как (если вообще) следует адаптироваться. Как только старый RFC устарел, должно быть достаточно безопасно придерживаться нового. - person tripleee; 20.08.2012