Api почты для домена

Api почты для домена

Версия 1.1 build 401, 2018-11-03 18:14:52 API Я ПДД api-pdd-v1.pdf — используется здесь. Новое — тут Сырцы https://github.com/i17/yapdd-jsclient [+] Описание

API Яндекс.Почты для доменов позволяет производить административные действия над вашими ящиками из программного кода (например, из кода вашего сайта).

API представляет собой интерфейс http(s) вызовов. Каждый вызов выполняет какое-то действие. Параметры передаются в строке запроса или в теле запроса. Все параметры надо передавать в кодировке urlencode. Результат выдается в теле ответа.

Я для себя и других администраторов доменов, которые захотели или захотят перейти на ЯПДД, написал генератор этих ссылок для вызовов, т.к. мне не удобно было пользоваться не-API вариантом Яндекса. Неудобство, которое признал Яндекс, касается установки переадресации почты у пользователей, например, на время их отпуска. На момент написания программы (2011-05-01) для того, чтобы установить переадресацию, администратору домена необходимо:

  1. Залогиниться под адресом, с которого надо установить переадресацию
  2. Создать правило сортировки, пересылающее письма на второй адрес
  3. Разлогиниться
  4. Залогиниться под вторым адресом, открыть сообщение, запрашивающее подтверждение желания получать переадресованные письма
  5. Перейти по ссылке, указанной в письме и получить сообщение, что эту ссылку следует переслать по первому адресу
  6. Вновь перелогиниться под первым адресом и перейти по этой ссылке
  7. Нажать кнопку, включающую таки переадресацию, поражаясь абсурду, что ты сам себе подтверждаешь включение переадресации.

Если Яндекс доведёт процедуру до простоты API, в представленном костыле надобности не будет.

Особенность реализации такая, что мне на сервер не передаётся Ваш токен, который является ключом к управлению вашей ЯПДД, т.к. токен хранится в части адресной строки после знака "#", который используется для адресации внутренних переходов по странице. Так задумал для тех, кто не хочет давать мне свой токен. Можете проверить любым снифером: не передаётся, как и другие переменные. Меньше знаю — крепче сплю, и вообще, сами админьте свою почту =) Для пущей безопасности, никаких сторонних скриптов (типа статистики, фреймворков) тоже не подключал — всё написано с нуля мной, админом почемубынета. Для общения с сервером Яндекса ссылки генерятся с протоколом "https".

После выполнения первого пункта (Активации API), можно поставить токен в предлагаемое поле и добавить страницу в закладки (избранное). В дальнейшем, просто можете держать эту страничку открытой и выполнять из неё какие-нибудь действия, заполняя поля, переходя по ссылкам и читая ответы. В Хроме ответы сервера могут казаться пустыми — надо смотреть код страницы.

Сам — разумеется — пользуюсь этой своей программой для нескольких доменов. Для каждого — своя закладка.

Вижу некоторые недостатки интерфейса. Обновлять версии — кнопкой F5. Конструктивные предложения — рассматриваю, токены — нет =)

2015-05-15: Буилд 360. По просьбам поменял местами несколько пунктов. Сделал, чтобы логины менялись во всех полях. Раньше логин в регистрации пользователя был независим.

2015-05-15: Буилд 352. Поменял кодировку на UTF-8.

2014-10-14: Буилд 350. Поменял длину рандомно генерируемых полей в соответствии с ограничениями ЯПДД.

2012-09-30: Буилд 348. Поменял адрес API.

2011-09-27: Буилд 347. Добавлено название домена в заголовок.

2011-09-12: Буилд 335. По просьбе пользователя добавил пункты API 30,31,32 про дополнительных админов домена. И заодно добавил пункты 33а, 33б — про общий список рассылки.

2011-08-10: Буилд 330. По просьбе пользователя добавил ссылку на простой вход в ЯПДД через https://mail.yandex.ru/for/domainname. От себя добавил ещё https-ссылку на управление ЯПДД через родной интерфейс. В шапке ссылку http://pdd.yandex.ru/ сделал SSL-ной. Поднял номер версии до 1.1.

2011-08-10: Буилд 300 (тот же). Внезапно замечено, что Яндекс исправился и теперь пункты 27 и 28 (авторизация по временному токену) работают.

2011-05-11: Буилд 300. Рождение версии 1.0. Пункт 28 не работает по причине Яндекса.

Каждый раз поднимая новый сервер в облаках, вы получаете случайный IP-адрес. Не все понимают, что IP-адрес может попасть к вам с "историей". Часто приходится тратить время на удаление IP из публичных черных списков. В моём случае в последний раз это была очень неторопливая переписка с mail.ru, которая ни к чему не привела. После этого, создав новый сервер, я задумался: как же сделать так, чтобы не огребать проблем с такими IP-адресами?

Введение

Несмотря на то, что серверы у меня могут быть как постоянные так и "на поиграться", почту на всех них я не обслуживаю, но очень хочу получать сервисные письма от своих скриптов и системных служб.

Очевидное решение — сделать свой "порядочный" почтовый шлюз и все остальные серверы настраивать на пересылку почты через этот шлюз. Минусы такого решения очевидны:

  • Отдельный сервер стоит денег, даже если это дешевая VPSка
  • IP-адрес надо постоянно отслеживать в черных списках
  • Настройка почтового шлюза требует времени, которое зависит от ваших скиллов

Из-за вышеперечисленных причин я пошёл искать другое решение, и, что характерно, нашёл.

Решение

Я обнаружил возможность схалявить, воспользовавшись сервисом "Почта для Домена" от Yandex. На тот момент у меня было поднято 3 сервера и в DNS были следующие А-записи:

Хост Тип Значение example.com A 123.123.123.120 server1.example.com A 123.123.123.121 server2.example.com A 123.123.123.122 server3.example.com A 123.123.123.123

Я зарегистрировал свой технический домен в "Почте для Домена" и создал аккаунт: root@example.com . Попробовал отправить письма с одного из своих серверов, используя этот SMTP-аккаунт и получил следующую ошибку:

Yandex не разрешает подставлять какие попало данные в envelope-from . Но как же быть, если хочется понимать, с какого сервера пришло то или иное письмо, без дополнительных ухищрений?

Чтобы соблюсти правила Yandex’a, нужно выполнить следующие шаги на стороне их сервиса:

Зарегистрировать основной домен и его поддомены в pdd.yandex.ru. Проще всего пройти подтверждение домена через добавление CNAME-записи:

Хост Тип Значение
example.com CNAME verification-code
server1.example.com CNAME verification-code
server2.example.com CNAME verification-code
server3.example.com CNAME verification-code
Читайте также:  Garmin nuvi 205w прошивка 2017

Так же для каждого домена создаем MX-запись:

Хост Тип Приоритет Значение
example.com MX 10 mx.yandex.ru
server1.example.com MX 10 mx.yandex.ru
server2.example.com MX 10 mx.yandex.ru
server3.example.com MX 10 mx.yandex.ru

В настройках основного домена указать поддомены как алиасы этого домена.

Создаём почтовый аккаунт root@example.com , если он ещё не создан

Обязательно нужно зайти в аккаунт через веб-интерфейc и активировать его, иначе получите ошибку:

Дальше требуется работа на нашей стороне — настраиваем сервера:

    Устанавливаем msmtp — миниатюрный SMTP-клиент, который предоставляет свою реализацию sendmail

Отправляем тестовое письмо с отладкой:

и смотрим результат:

Отлично, успех! Письмо ушло, правда, найдем мы его в спаме, так как оно почему-то пустое. Давайте проверим более привычным и "человеческим" способом:

Вот, теперь в ящике нормальное письмо. Здорово!

DKIM & SPF

А еще можно для каждого домена прописать записи DKIM и SPF. Если вы, как я, используете свой DNS-хостинг, то просто скопируйте соответствующие значения из “DNS редактора” в интерфейсе Яндекса. Внимание: для каждого домена и алиаса свой ключ!

Хост Тип Значение
mail._domainkey.example.com TXT v=DKIM1; k=rsa; t=s; p=MIGf.
mail._domainkey.server1.example.com TXT v=DKIM1; k=rsa; t=s; p=MIGf.
mail._domainkey.server2.example.com TXT v=DKIM1; k=rsa; t=s; p=MIGf.
mail._domainkey.server3.example.com TXT v=DKIM1; k=rsa; t=s; p=MIGf.

Отсылаем с сервера письмо и смотрим в заголовки:

В случае если отправка почты для домена будет происходить только через сервера Яндекс и с заранее известных IP-адресов, то можно смело прописать SPF-записи в соответствии с документацией https://yandex.ru/support/pdd/troubleshooting/dns.xml#step2

Хост Тип Значение
example.com TXT v=spf1 redirect=_spf.yandex.net
server1.example.com TXT v=spf1 redirect=_spf.yandex.net
server2.example.com TXT v=spf1 redirect=_spf.yandex.net
server3.example.com TXT v=spf1 redirect=_spf.yandex.net

Нюансы

Скорее всего, вы молодцы, и ваше приложение работает не из под root’а. Попытка послать письмо из-под обычного пользователя опять приведёт к знакомой ошибке в логе msmtp:

Можно решить эту проблему по-разному. Например, можно явно указывать пользователя, отключив опцию auto_from off в msmtp . Но я уже решил, что меня это не устраивает.

Правильное решение — добавить пользователя как алиас для нашего основного адреса:

Если вам требуется локальный SMTP-релей, то данная конфигурация вам тоже подходит. Нужно просто заменить msmtp на postfix или exim, настроенные на использование серверов Яндекса в качестве smart host’a (гуглить можно, например, по ключевым словам exim smarthost).

Резюме

Теперь любой сервер, который я поднимаю для своих задачек, сразу же получает настроенный канал отправки почты. В DNS и pdd.yandex.ru я заранее прописал несколько поддоменов про запас. Так как сервера я разворачиваю через SaltStack, то конфигурацию msmtp мои сервера получают автоматически.

Что я получил в итоге:

  1. Самое главное — нет заморочек с черными списками и IP-адресами серверов, так как письма уходят через сервера Яндекса
  2. DKIM/SPF "из коробки" — письма не попадают в спам
  3. msmtp простой SMTP-клиент, которому даже в памяти сервера висеть не нужно — запускается по необходимости
  4. msmtp — простейшая настройка в отличие от "взрослых" postfix, exim
  5. можно не беспокоиться о PTR-записях для ваших IP-адресов с точки зрения почтовой системы.

Надеюсь эта инструкция кому-нибудь пригодится. Буду рад узнать из комментариев, кто и как решает подобную проблему.

Похожие публикации

  • 4 апреля 2016 в 07:57

Брэндированный DNS или white labeling на Amazon Route 53

Комментарии 21

Например на http://pastebin.com/. Уверен, что кроме меня найдутся и другие кому тоже интересно)

# This is a default configuration file which will operate correctly in
# uncomplicated installations. Please see the manual for a complete list
# of all the runtime configuration options that can be included in a
# configuration file. There are many more than are mentioned here. The
# manual is in the file doc/spec.txt in the Exim distribution as a plain
# ASCII file. Other formats (PostScript, Texinfo, HTML, PDF) are available
# from the Exim ftp sites. The manual is also online at the Exim web sites.

# This file is divided into several parts, all but the first of which are
# headed by a line starting with the word «begin». Only those parts that
# are required need to be present. Blank lines, and lines starting with #
# are ignored.

########### IMPORTANT ########## IMPORTANT ########### IMPORTANT ###########
# #
# Whenever you change Exim’s configuration file, you *must* remember to #
# HUP the Exim daemon, because it will not pick up the new configuration #
# until you do. However, any other Exim processes that are started, for #
# example, a process started by an MUA in order to send a message, will #
# see the new configuration as soon as it is in place. #
# #
# You do not need to HUP the daemon for changes in auxiliary files that #
# are referenced from this file. They are read every time they are used. #
# #
# It is usually a good idea to test a new configuration for syntactic #
# correctness before installing it (for example, by running the command #
# «exim -C /config/file.new -bV»). #
# #
########### IMPORTANT ########## IMPORTANT ########### IMPORTANT ###########

# Specify your host’s canonical name here. This should normally be the fully
# qualified «official» name of your host. If this option is not set, the
# uname() function is called to obtain the name. In many cases this does
# the right thing and you need not set anything explicitly.

# The next three settings create two lists of domains and one list of hosts.
# These lists are referred to later in this configuration using the syntax
# +local_domains, +relay_to_domains, and +relay_from_hosts, respectively. They
# are all colon-separated lists:

domainlist local_domains = @: localhost: localhost.localdomain
domainlist relay_to_domains =
hostlist relay_from_hosts = localhost
# (We rely upon hostname resolution working for localhost, because the default
# uncommented configuration needs to work in IPv4-only environments.)

Читайте также:  Fly две сим карты

# Most straightforward access control requirements can be obtained by
# appropriate settings of the above options. In more complicated situations,
# you may need to modify the Access Control Lists (ACLs) which appear later in
# this file.

# The first setting specifies your local domains, for example:
#
# domainlist local_domains = my.first.domain: my.second.domain
#
# You can use "@" to mean «the name of the local host», as in the default
# setting above. This is the name that is specified by primary_hostname,
# as specified above (or defaulted). If you do not want to do any local
# deliveries, remove the "@" from the setting above. If you want to accept mail
# addressed to your host’s literal IP address, for example, mail addressed to
# «user@[192.168.23.44]», you can add "@[]" as an item in the local domains
# list. You also need to uncomment «allow_domain_literals» below. This is not
# recommended for today’s Internet.

# The second setting specifies domains for which your host is an incoming relay.
# If you are not doing any relaying, you should leave the list empty. However,
# if your host is an MX backup or gateway of some kind for some domains, you
# must set relay_to_domains to match those domains. For example:
#
# domainlist relay_to_domains = *.myco.com: my.friend.org
#
# This will allow any host to relay through your host to those domains.
# See the section of the manual entitled «Control of relaying» for more
# information.

# The third setting specifies hosts that can use your host as an outgoing relay
# to any other host on the Internet. Such a setting commonly refers to a
# complete local network as well as the localhost. For example:
#
# hostlist relay_from_hosts = =<$message_size> <100000><1>>
# add_header = X-Spam-Note: SpamAssassin run bypassed due to message size

# Run SpamAssassin, but allow for it to fail or time out. Add a warning message
# and accept the mail if that happens. Add an X-Spam-Flag: header if the SA
# score exceeds the SA system threshold.
#
# warn spam = nobody/defer_ok
# add_header = X-Spam-Flag: YES
#
# accept condition = $>
# add_header = X-Spam-Note: SpamAssassin invocation failed
#

# Unconditionally add score and report headers
#
# warn add_header = X-Spam-Score: $spam_score ($spam_bar)

# X-Spam-Report: $spam_report

# And reject if the SpamAssassin score is greater than ten
#
# deny condition = $<$spam_score_int> <100><1>>
# message = Your message scored $spam_score SpamAssassin point. Report follows:

# $spam_report

# Trigger greylisting (if enabled) if the SpamAssassin score is greater than 0.5
#
# warn condition = $<$spam_score_int> <5><1>>
# set acl_m_greylistreasons = Message has $spam_score SpamAssassin points
$acl_m_greylistreasons

# If you want to greylist _all_ mail rather than only mail which looks like there
# might be something wrong with it, then you can do this…
#
# warn set acl_m_greylistreasons = We greylist all mail
$acl_m_greylistreasons

# Now, invoke the greylisting. For this you need to have installed the exim-greylist
# package which contains this subroutine, and you need to uncomment the bit below
# which includes it too. Whenever the $acl_m_greylistreasons variable is non-empty,
# greylisting will kick in and will defer the mail to check if the sender is a
# proper mail which which retries, or whether it’s a zombie. For more details, see
# the exim-greylist.conf.inc file itself.
#
# require acl = greylist_mail

# To enable the greylisting, also uncomment this line:
# .include /etc/exim/exim-greylist.conf.inc

begin routers
yandex_route:
driver = manualroute
transport = yandex_relay
route_list = * smtp.yandex.ru

# This router routes to remote hosts over SMTP by explicit IP address,
# when an email address is given in «domain literal» form, for example,
# . The RFCs require this facility. However, it is
# little-known these days, and has been exploited by evil people seeking
# to abuse SMTP relays. Consequently it is commented out in the default
# configuration. If you uncomment this router, you also need to uncomment
# allow_domain_literals above, so that Exim can recognize the syntax of
# domain literal addresses.

# domain_literal:
# driver = ipliteral
# domains =! +local_domains
# transport = remote_smtp

# This router routes addresses that are not in local domains by doing a DNS
# lookup on the domain name. The exclamation mark that appears in «domains =!
# +local_domains» is a negating operator, that is, it can be read as «not». The
# recipient’s domain must not be one of those defined by «domainlist
# local_domains» above for this router to be used.
#
# If the router is used, any domain that resolves to 0.0.0.0 or to a loopback
# interface address (127.0.0.0/8) is treated as if it had no DNS entry. Note
# that 0.0.0.0 is the same as 0.0.0.0/32, which is commonly treated as the
# local host inside the network stack. It is not 0.0.0.0/0, the default route.
# If the DNS lookup fails, no further routers are tried because of the no_more
# setting, and consequently the address is unrouteable.

#dnslookup:
# driver = dnslookup
# domains =! +local_domains
# transport = remote_smtp
# ignore_target_hosts = 0.0.0.0: 127.0.0.0/8
# if ipv6-enabled then instead use:
# ignore_target_hosts = # This authenticator supports CRAM-MD5 username/password authentication
# with Exim acting as a _client_, as it might when sending its outgoing
# mail to a smarthost rather than directly to the final recipient.
# Replace SMTPAUTH_USERNAME and SMTPAUTH_PASSWORD as appropriate.

#client_auth:
# driver = cram_md5
# public_name = CRAM-MD5
# client_name = SMTPAUTH_USERNAME
# client_secret = SMTPAUTH_PASSWORD

# The following authenticators support plaintext username/password
# authentication using the standard PLAIN mechanism and the traditional
# but non-standard LOGIN mechanism, with Exim acting as the server.
# PLAIN and LOGIN are enough to support most MUA software.
#
# These authenticators are not complete: you need to change the
# server_condition settings to specify how passwords are verified.
# They are set up to offer authentication to the client only if the
# connection is encrypted with TLS, so you also need to add support
# for TLS. See the global configuration options section at the start
# of this file for more about TLS.
#
# The default RCPT ACL checks for successful authentication, and will accept
# messages from authenticated users from anywhere on the Internet.

Читайте также:  1С розница как провести инвентаризацию

# PLAIN authentication has no server prompts. The client sends its
# credentials in one lump, containing an authorization ID (which we do not
# use), an authentication ID, and a password. The latter two appear as
# $auth2 and $auth3 in the configuration and should be checked against a
# valid username and password. In a real configuration you would typically
# use $auth2 as a lookup key, and compare $auth3 against the result of the
# lookup, perhaps using the crypteq<><> condition.

#PLAIN:
# driver = plaintext
# server_set_ > # server_prompts =:
# server_condition = $<$3>> <1>>
# server_advertise_condition = $

# LOGIN authentication has traditional prompts and responses. There is no
# authorization ID in this mechanism, so unlike PLAIN the username and
# password are $auth1 and $auth2. Apart from that you can use the same
# server_condition setting for both authenticators.

#LOGIN:
# driver = plaintext
# server_set_ > # server_prompts =

API Яндекс-Почта для домена + PowerShell: создаём ящики пакетом из .csv файла

В некоторых предыдущих статьях уже затрагивал Яндекс API сервиса “Почта для домена”. Могу похвастаться тем, что добил таки модуль PowerShell, реализующий командлеты для использования указанного API в PowerShell. И в качестве первой задача – создание произвольного количества ящиков и группы рассылки, состоящей из этих ящиков, на базе данных из .csv файла.

Бочка мёда

Для затравки приведу код сценария, использующего разработанный модуль powershell:

Как видно, после импорта модуля и прочих заголовков в 6 строк мы загружаем данные о пользователях из .csv файла, создаём для каждого пользователя ящик на припаркованном на Яндекс домене ”csm.nov.ru”, и включаем адрес пользователя в группу рассылки all на том же домене.

Удобно? Самому понравился результат. В дополнение скажу: командлеты поддерживают параметры –verbose, –confirm, –debug, –whatif.

А где же улей?

Целиком проект со всеми зависимостями лучше всего получить с git репозитория – https://github.com/sergey-s-betke/Users. Он содержит submodules, поэтому не забудьте после git clone обновить модули.

Чуть ближе к дёгтю

А теперь к самому модулю ITG.Yandex.PDD. Размещён он так же в git репозитории на github – ITG.Yandex.PDD. Приведу код модуля, хотя он получился огромным.

Код приведён здесь только для ознакомления, его текущие версии – только в github.

А теперь – большая ложка дёгтя!

В процессе создания этого модуля изучил API Google Apps. Google мало того, что предоставляет формализованное описание API (SOAP, для некоторых API – WADL), так ещё и поставляет готовые библиотеки для многих языков программирования. В PowerShell мы вполне могли бы использовать .net сборку. Яндекс не предлагает библиотек. Но страшно не это. Яндекс не предлагает и формализованного описания ни в одном более менее промышленном стандарте! Разработчики активно спорят с потенциальными “потребителями” своего API по вопросу выбора архитектуры API: почему REST, а не SOAP. Хотя предлагаемое API нельзя отнести к разряду критичных по времени, а по сему – лучшим на мой взгляд был бы именно SOAP, – не важно, REST так REST. Но что мешало и для REST API разместить хотя бы WADL описание? Но этого нет. Поэтому автоматизировать процесс создания модуля – обёртки по формализованному описанию возможности не представилось.

Кроме того, в процессе программирования выявились несоответствия заявленной в документации схемы ответов фактической. И, опять-таки, xml схема ответов не описана никакими средствами, кроме как русским языком.

И не в последнюю очередь следует отметить бедность API по сравнению с web интерфейсом. В частности, управление группами рассылок ограничено созданием general maillist – группы рассылки, включающей в себя все адреса домена, в том числе – и других групп рассылок. При этом циклы не анализируются на этапе создания (проверял!). Именно поэтому в коде командлет, управляющих группами рассылок, Вы найдёте неочевидные действия и откровенные заплатки (в частности, при создании группы рассылки мне пришлось создавать general maillist, ждать, пока в асинхронном исполнении Яндекс заполнит группу всеми адресами домена, после чего – удалять их все с тем, чтобы дать возможность самостоятельного управления членством в группе.

Ощущается архитектурная ошибка, приводящая к столь различному уровню API, пользовательского интерфейса и API ядра:пользовательский интерфейс посредством AJAX использует иные интерфейсы, нежели предложены нам в API. Поэтому возможности пользовательского интерфейса и API столь различаются. Остаётся только в качестве образца здесь привести инициативу Microsoft аж 2007 года – всё управление – через powershell. В том числе и все визуальные консоли управления – через сценарии powershell взаимодействуют с управляемыми объектами. И теперь, через 5 лет, мы видим результаты – через powershell действительно мы можем сделать практически всё, что можем и через визуальные средства управления, и даже существенно больше!

Итого, выводы: работать с Яндекс.API Почты для домена на сегодня можно. Но сравнивать с Google Apps API даже не стоит – просто разного уровня API. Одно решение – “для себя”, другое – “для людей”. Надеюсь, в скором времени ситуация с API у Яндекс изменится к лучшему… Хочется, всё-таки, гордиться отечественным продуктом, а не продуктом Google.

Ссылка на основную публикацию
Adblock detector