Тонкости рассылок
запросы:
база активных емейлов
рассылки по базам ( цель- рассылка по базам с емейлом и номером телефона )
RTime:
Позвонил я на телефон 8800 "е- почты"- продвинутого сервиса софта для рассылок.
И тут мне оператор и говорит-
что, мол, без разницы- какой софт ты используешь, а всё полностью зависит от сервера,
через который ты делаешь емейл- рассылки.
Списки SMTP серверов для рассылки электронной почты http://www.epochta.ru/support/smtp/
Что такое SMTP?
SMTP (англ. Simple Mail Transfer Protocol — простой протокол передачи почты) — это сетевой протокол, предназначенный для передачи электронной почты
SMTP-сервер выполняет две функции:
- Проверяет правильность настроек и выдает разрешение компьютеру, пытающемуся отправить email-сообщение;
- Отправляет исходящее сообщение на указанный адрес и удостоверяется в успешной доставке сообщения. Если его невозможно доставить, отправителю направляется сообщение об этом.
Где можно получить SMTP-сервер для рассылки?
Есть несколько вариантов, выбор оптимального зависит от количества сообщений, которые вы собираетесь отправлять.
- Сервис SendPulse SMTP
- Сервис SMTP.com
- SMTP вашего Интернет-провайдера
- Бесплатные email-сервисы с поддержкой SMTP (Gmail и другие)
- SMTP-сервер вашего хостинга (если у вас есть сайт)
- Виртуальный сервер (VPS)
SendPulse SMTP
Компания SendPulse предоставляет качественный SMTP-сервер для ваших рассылок.
Основные преимущества сервиса:
- Используйте привычное программное обеспечение, как ePochta Mailer, так и любую другую программу
- Больший процент доставки во "входящие" благодаря поддержке SPF
- Удаление адресов, которым не доставлено сообщение (bounce), отписавшихся через smtp-сервис и "мертвых" доменов (интеграция с ePochta Mailer)
- Поддержка альтернативных портов (25 или 2525) для избежания ограничений Интернет-провайдера
- Идеальное решение для больших объемов исходящей почты (обработка заказов, новости, уведомления, маркетинг и т.д.)
- Нет необходимости покупки серверного оборудования или программного обеспечения. Надежный сервис с гарантированным аптаймом 99.999%
- Доступная ежемесячная плата и мгновенная активация
(вики) решает- сколько писем идёт с твоего айпи.
SMTP-сервер исходящей почты
Почтовый клиент должен знать IP-адрес SMTP-сервера, который задается как часть конфигурации (обыкновенно в виде DNS-имени). Сервер будет доставлять исходящие сообщения от лица пользователя.
Ограничения доступа к серверу исходящей почты
Администраторам сервера необходимо контролировать то, какие клиенты могут использовать сервер. Это позволяет им бороться с такими злоупотреблениями, как спам. Обычно используются два решения:
- В прошлом многие системы вводили ограничения по местоположению клиента, допуская к использованию лишь тех, чей IP-адрес был среди подконтрольных администраторам.
- Современные сервера обычно предлагают альтернативную систему, требующую аутентификацию клиентов для получения доступа.
Ограничение доступа по местоположению
В этом случае SMTP-сервер интернет-провайдера не разрешит допуск пользователям «за пределами» сети провайдера. Точнее, сервер может допустить лишь тех пользователей, чей IP-адрес предоставлен данным провайдером, что эквивалентно требованию соединения с Интернетом с помощью этого провайдера. Мобильный пользователь часто может оказаться в сети, отличной от сети своего провайдера, и потому сообщения не будут отправляться.
У данной системы есть несколько разновидностей. Например, SMTP-сервер организации может предоставлять доступ только пользователям той же сети, блокируя остальных пользователей. Также сервер может проводить ряд проверок клиентского IP-адреса. Эти методы обычно использовались организациями и учреждениями, например университетами, для внутреннего пользования сервером. Однако, большая их часть теперь использует описанные ниже методы аутентификации.
Благодаря ограничению доступа определенным адресам, администраторы сервера могут легко определить адрес любого злоумышленника. Если пользователь может использовать различные провайдеры для соединения с Интернетом, этот вид ограничения становится нецелесообразным, а изменение настроенного адреса SMTP-сервера исходящей почты непрактично. Крайне желательно иметь возможность использовать такую информацию о настройках клиента, которая не нуждается в изменении.
Аутентификация клиента
Вместо описанного ранее ограничения по местоположению, современные SMTP-сервера обычно требуют аутентификацию пользователей перед получением доступа. Эта система, будучи более гибкой, поддерживает мобильных пользователей и предоставляет им фиксированный выбор настроенного сервера исходящей почты.
Открытый релей
Сервер, доступный для широкой сети и не предоставляющий эти виды ограничения доступа, называют открытым релеем. Сейчас такие сервера считаются дурным тоном.
Порты
Администраторы сервера выбирают, какой порт будут использовать клиенты для ретрансляции исходящей почты - 25 или 587. Спецификации и многие сервера поддерживают и тот, и другой порты. Хотя некоторые сервера поддерживают порт 465 для безопасного SMTP, но предпочтительнее использовать стандартные порты и ESMTP-команды, если необходима защищённая сессия между клиентом и сервером.
Некоторые сервера настроены на отклонение всех ретрансляций по порту 25, но пользователям, прошедшим аутентификацию по порту 587, позволено перенаправлять сообщения на любой действительный адрес.
Некоторые провайдеры перехватывают порт 25, перенаправляя трафик на свой собственный SMTP-сервер вне зависимости от адреса назначения. Таким образом, их пользователи не могут получить доступ к серверу за пределами провайдерской сети по порту 25.
Некоторые сервера поддерживают аутентифицированный доступ по дополнительному, отличному от 25, порту, позволяя пользователям соединяться с ними, даже если порт 25 заблокирован.
Пример простейшей SMTP-сессии
C: — клиент, S: — сервер
S: (ожидает соединения) C: (Подключается к порту 25 сервера) S:220 mail.company.tld ESMTP 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: Some User <someusername@somecompany.ru> C:To: User1 <user1@company.tld> C:Subject: tema C:Content-Type: text/plain 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
предписывает начинать сессию не командой 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
- RFC 2822
- 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 821aka 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.
См. также
- LMTP — производный от SMTP протокол, ориентированный на работу без очереди сообщений.
- POP3
- IMAP
- TCP
- Sender Policy Framework
- Sender ID
- X.400
- Предотвращение утечек информации через SMTP
| [скрыть]Схемы URI | |
|---|---|
| [скрыть]Основные протоколы TCP/IP по уровням модели OSI (Список портов TCP и UDP) | |
|---|---|
