| Murzilka | Дата: Четверг, 10.01.2013, 06:21 | Сообщение # 1 |
 Генералиссимус
Группа: Администраторы
Сообщений: 1617
Статус: Offline
| Пример простейшей SMTP-сессии
C: — клиент, S: — сервер
S: (ожидает соединения)
C: (Подключается к порту 25 сервера)
S:220 mail.company.tld ESMTP CommuniGate Pro 5.1.4i is glad to see you!
C:HELO
S:250 domain name should be qualified
C:MAIL FROM: <someusername@somecompany.ru>
S:250 someusername@somecompany.ru sender accepted
C:RCPT TO:<user1@company.tld>
S:250 user1@company.tld ok
C:RCPT TO: <user2@company.tld>
S:550 user2@company.tld unknown user account
C:DATA
S:354 Enter mail, end with "." on a line by itself
C:from: someusername@somecompany.ru //чтобы письмо
C:to: user1@company.tld //не было добавлено
C:subject: tema //в категорию спам
C: //
C:Hi!
C:.
S:250 769947 message accepted for delivery
C:QUIT
S:221 mail.company.tld CommuniGate Pro SMTP closing connection
S: (закрывает соединение)
В результате такой сессии письмо будет доставлено адресату user1@company.tld , но не будет доставлено адресату user2@company.tld , потому что такого адреса не существует.
Дополнительные расширения
Многие клиенты запрашивают расширения SMTP, поддерживаемые сервером, с помощью команды EHLO из спецификации расширенного SMTP (RFC 1870). HELO используется только в том случае, если сервер не ответил на EHLO. Современные клиенты могут использовать ключ SIZE расширения ESMTP для запроса максимального размера сообщения, которое будет принято. Более старые клиенты и сервера могут попытаться передать чрезмерно большие сообщения, которые будут отклонены после потребления сетевых ресурсов, включая время соединения. Пользователи могут вручную заранее определить максимальный размер, принимаемый ESMTP-серверами. Клиент заменяет команду HELO на EHLO.
S: 220 smtp2.example.com ESMTP Postfix
C: EHLO bob.example.org
S: 250-smtp2.example.com Hello bob.example.org [192.0.2.201]
S: 250-SIZE 14680064
S: 250-PIPELINING
S: 250 HELP
smtp2.example.com объявляет ,что он примет сообщение размером не больше чем 14,680,064 октетов (8-битных байтов). В зависимости от фактического использования сервера, он может на данный момент не принять сообщение такой величины. В простейшем случае, ESMTP-сервер объявит максимальный SIZE только при взаимодействии с пользователем через EHLO.
Безопасность SMTP и спам
Изначальная спецификация SMTP не включала средств для аутентификации отправителей. Впоследствии, в RFC 2554 было введено расширение . Расширение SMTP (ESMTP) предоставляет почтовым клиентам механизм задания механизма обеспечения безопасности для сервера, аутентификации и профиля безопасности SASL (Simple Authentication and Security Layer) для последующих передач сообщений.
Продукты Microsoft реализуют собственный протокол - SPA (Secure Password Authentication) с помощью расширения SMTP-AUTH.
Однако, непрактичность широкого распространения реализации и управления SMTP-AUTH означает, что проблема спама не может быть решена с его помощью.
Обширное изменение SMTP, так же как и полная его замена, считаются непрактичными из-за огромной инсталированной базы SMTP. Internet Mail 2000 был одним из претендентов для такой замены.
Спам функционирует благодаря различным факторам, в том числе не соответствующие стандартам реализации MTA, уязвимости в защите операционных систем (усугубляемые постоянным широкополосным подключением), что позволяет спамерам удаленно контролировать компьютер конечного пользователя и посылать с него спам.
Существует несколько предложений для побочных протоколов, помогающих работе SMTP. Исследовательская группа Anti-Spam (The Anti-Spam Research Group - ASRG) - подразделение Исследовательской группы Интернет-технологий работает над почтовой аутентификацией и другими предложениями для предоставления простой аутентификации, которая будет гибкой, легковесной и масштабируемой. Недавняя деятельность Инженерного совета Интернета (IETF) включает в себя MARID (2004), приведший к двум утвержденным IETF-экспериментам в 2005, и DomainKeys Identified Mail в 2006.
Расширения ESMTP
RFC 1869 предписывает начинать сессию не командой HELO, а командой EHLO. В случае, если сервер не поддерживает расширений, то он ответит на EHLO ошибкой, в этом случае клиент должен послать команду HELO и не использовать расширения протокола.
Если же сервер поддерживает ESMTP, то кроме приветствия он сообщит список поддерживаемых расширений протокола SMTP, например:
ehlo office.company1.tld
250-mail.company2.tld is pleased to meet you
250-DSN
250-SIZE
250-STARTTLS
250-AUTH LOGIN PLAIN CRAM-MD5 DIGEST-MD5 GSSAPI MSN NTLM
250-ETRN
250-TURN
250-ATRN
250-NO-SOLICITING
250-HELP
250-PIPELINING
250 EHLO
Стандарты RFC
RFC 1870 SMTP Service Extension for Message Size Declaration (заменяет RFC 1653)
RFC 2034 SMTP Service Extension for Returning Enhanced Error Codes
RFC 2505 Anti-Spam Recommendations for SMTP MTAs (BCP 30)
RFC 4954 SMTP Service Extension for Authentication (заменяет RFC 2554)
RFC 2822 Internet Message Format (заменяет RFC 822 aka STD 11)
RFC 2920 SMTP Service Extension for Command Pipelining (STD 60)
RFC 3030 SMTP Service Extensions for Transmission of Large and Binary MIME Messages
RFC 3207 SMTP Service Extension for Secure SMTP over Transport Layer Security (заменяет RFC 2487)
RFC 3461 SMTP Service Extension for Delivery Status Notifications (заменяет RFC 1891)
RFC 3462 The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages (заменяет RFC 1892)
RFC 3463 Enhanced Status Codes for SMTP (заменяет RFC 1893)
RFC 3464 An Extensible Message Format for Delivery Status Notifications (заменяет RFC 1894)
RFC 3552 Guidelines for Writing RFC Text on Security Considerations
RFC 3834 Recommendations for Automatic Responses to Electronic Mail
RFC 4409 Message Submission for Mail (заменяет RFC 2476)
RFC 5321 Simple Mail Transfer Protocol (заменяет RFC 821 aka STD 10, RFC 974, RFC 1869, RFC 2821)
RFC 5336 SMTP Extension for Internationalized Email Addresses
Перевод RFC 2505 — Рекомендации по предотвращению спама для SMTP MTA
Перевод RFC 2554 — Расширение сервиса SMTP для аутентификации
Перевод RFC 5321 — Простой протокол передачи электронной почты (SMTP)
Литература
Hughes L Internet e-mail Protocols, Standards and Implementation. — Artech House Publishers, 1998. — ISBN 0-89006-939-5
Hunt C sendmail Cookbook. — O'Reilly Media, 2003. — ISBN 0-596-00471-0
Johnson K Internet Email Protocols: A Developer's Guide. — Addison-Wesley Professional, 2000. — ISBN 0-201-43288-9
Loshin P Essential Email Standards: RFCs and Protocols Made Practical. — John Wiley & Sons, 1999. — ISBN 0-471-34597-0
Rhoton J Programmer's Guide to Internet Mail: SMTP, POP, IMAP, and LDAP. — Elsevier, 1999. — ISBN 1-55558-212-5
Wood D Programming Internet Mail. — O'Reilly, 1999. — ISBN 1-56592-479-7
C уважением Некий Tomsik aka Мурзилка
А у вас есть ручка за 2.50?
|
| |
| |
