Exchange 2013 — message trace shows ExplicitlyDiscarded HAdiscard on inbound missing email
I have an inbound email that a Get-MessageTrackingLog shows as arriving past the CAS server and into the mailbox server, but then shows as ExplicitlyDiscarded and HAdiscard.
I can’t seem to find anything online other than that this is normal in deleting a shadowcopy from the primary mail server after delivering the email to the mailbox. However, in this instance there is no final actual DELIVER into the mailbox itself. The above is the final portion of the tracking log, which normally would state as «DELIVER» to the mailbox, but never got that far.
Any ideas on how to determine what happened here on why the mail was discarded before the email was delivered to the mailbox itself?
Troubleshooting message delivery and Shadow Redundancy real case example
Shadow redundancy was introduced in Exchange 2010 to provide redundant copies of messages before they’re delivered to mailboxes. It’s not a purpose if this post to describe, how this functionality works. Instead, we will look at real life practical example on how to troubleshoot issues with Shadow Redundancy.
If you’re not familiar with this one, review official tech doc here: Shadow redundancy in Exchange Server
Specific issue description
Assume, that our Exchange environment experience issues with duplicate email deliveries. This happens from time to time with different senders and recipients. We should expect, that we cannot trust any statistics. In Exchange Server we have duplicate delivery prevention option, i.e. message won’t be delivered twice, if it was delivered to mailbox already. Thus, theoretically this issue can happen more often, than noticeable by users.
But anyway, let’s try to troubleshoot this issue.
Troubleshooting steps
First thing I would ask for – examples of headers for duplicated messages. And message tracking logs for corresponding message id’s.
Let’s look at some useful information from headers.
This message was delivered first and overall looks normal. EndToEndLatency is small, AuthMechanism equals to 07, that means, that message was sent via smtp with authentication.
X-MS-Exchange-Organization-Network-Message-Id: 25cd2baf-60c1-4de7-8dc0-08db7048beb7
X-MS-Exchange-Organization-AuthSource: tr-ex1
X-MS-Exchange-Organization-AuthAs: Internal
X-MS-Exchange-Organization-AuthMechanism: 07
X-MS-Exchange-Transport-EndToEndLatency: 00:00:00.2310237
Second example – message was delivered after some time. EndToEndLatency is about 1 hour, we can see reference that it was sent with ShadowRedundancy, that confirmed by AuthMechanism that equals to 0c.
Received: from ex-tr2 (10.0.0.2) by ex-tr1
(10.0.0.1) with ShadowRedundancy id 15.2.922.19; Wed, 28 Jun 2023
23:07:57 +0000
X-MS-Exchange-Organization-Network-Message-Id: 7c5ed59c-60c1-4de7-8dc0-dbeb14920b77
X-MS-Exchange-Organization-AuthAs: Internal
X-MS-Exchange-Organization-AuthMechanism: 0c
X-MS-Exchange-Transport-EndToEndLatency: 00:58:07.1796301
From here, we can confirm, that message was resubmitted by Shadow Redundancy. What’s interesting, Network-Message-Id is different for these messages, that’s why message was delivered twice against duplicate delivery. I wasn’t able to reproduce this issue in my test environment, but Exchange version in this case is really specific and was released 2 years ago.
Let’s look at message tracking logs from test environment.
HARECEIVE and HAREDIRECT events mean, that shadow copy was created successfully. But no HADISCARD events were registered for this message. That means, that message is still in shadow queue.
In real life example, message was resubmitted from shadow queue after some time. Let’s look at this process in more detail.
Server TR-EX2 created shadow copy of message on server TR-EX1. Corresponding queue state on TR-EX1:
If we dig into message tracking log, we can also notice, that Exchange is not able to create shadow copies on TR-EX2.
“Service not available” usually means, that we have issues with network connectivity, appropriate connector doesn’t exist, or some settings don’t correspond to what we expect.
Even more, we can investigate connectivity logs to see, what’s happening where.
HUB connectivity logs show the same error message (C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\Hub\Connectivity):
2023-06-28T11:40:28.843Z,08DB745BC9DF51B3,SMTP,tr-ex2.contoso.com,>,Established connection to 10.0.0.102
2023-06-28T11:40:28.843Z,08DB745BC9DF51B3,SMTP,tr-ex2.contoso.com,-,Messages: 0 Bytes: 0 (Retry : Service not available)
We can also expect different events in OS Application logs. But that depends from version \ issue.
For mail submission from database and shadow redundancy we use Default receive connector created upon Exchange Server installation. Not all internal communications are logged by default. To enable this for transport you should at least complete those configuration steps (for this specific issue):
Set-ReceiveConnector “TR-EX1\Default TR-EX1” -ProtocolLoggingLevel verbose
Set-TransportService TR-EX1 -IntraOrgConnectorProtocolLoggingLevel Verbose
So, the same issue we can see from SmtpSend logs (C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\Hub\ProtocolLog\SmtpSend) while tr-ex1 is trying to create shadow copy on tr-ex2.
2023-06-28T11:00:28.578Z,Intra-Organization SMTP Send Connector,08DB745BC9DF5177,0,,10.0.0.102:2525,,None,Set Session Permissions 2023-06-28T11:00:28.578Z,Intra-Organization SMTP Send Connector,08DB745BC9DF5177,1,,10.0.0.102:2525,,,attempting to connect
2023-06-28T11:00:28.579Z,Intra-Organization SMTP Send Connector,08DB745BC9DF5177,2,10.0.0.101:33826,10.0.0.102:2525,+,,
2023-06-28T11:00:28.579Z,Intra-Organization SMTP Send Connector,08DB745BC9DF5177,3,10.0.0.101:33826,10.0.0.102:2525,<,421 4.3.2 Service not available,
2023-06-28T11:00:28.579Z,Intra-Organization SMTP Send Connector,08DB745BC9DF5177,4,10.0.0.101:33826,10.0.0.102:2525,*,,Dropping connection because server is not accepting mail. Server response :421 4.3.2 Service not available
Let’s verify settings for appropriate connector on TR-EX2. Of cause, there can be another settings that can break all the staff. But these ones causing issues more often.
Everything looks OK despite of RemoteIPRanges. That property enables connections only from one IP address and this is not Exchange Server.
Note. Changes on Default connectors are not recommended and not desired. In this configuration unwanted changes broke Shadow Redundancy and Submission. That actually created a single point of Failure.
Let’s fix connector properties.
Now we can see corresponding events from smtp send logs:
2023-06-28T12:06:29.024Z,Intra-Organization SMTP Send Connector,08DB745BC9DF51DA,18,10.0.0.101:38607,10.0.0.102:2525,<,250 8HRSl3D3P0m2abo/1qRlww==, 2023-06-28T12:06:29.024Z,Intra-Organization SMTP Send Connector,08DB745BC9DF51DA,19,10.0.0.101:38607,10.0.0.102:2525,>,XQDISCARD 50,
In this case, services wasn’t restored after we fixed connector settings. For troubleshooting purposes we can use Get-ExchangeDiagnosticInfo -Server tr-ex2 -Process EdgeTransport -Component ShadowRedundancy -Argument Verbose
That cmdlets show configuration settings for specific component in one place and also provides some diagnostics information.
In our case LastHeartbeatTime showed that last attempt was before we fixed issue with configuration. Transport service and server were not restarted since than. So, we decided to restart service and issue was resolved.
In last Cu’s there are attempts to reset heartbeat state. So probably, this is not the case for latest versions.
Exchange 2013 — трассировка сообщения показывает ExplicitlyDiscarded HAdiscard на входящей недостающей электронной почте
У меня есть входящее электронное письмо, которое Получение-MessageTrackingLog показывает прибывающий мимо сервера CAS и в сервер почтовых ящиков, но затем показывает ExplicitlyDiscarded и HAdiscard.
Я, может казаться, не нахожу ничего онлайн, кроме которого это нормально в удалении shadowcopy от основного почтового сервера после поставки электронной почты к почтовому ящику. Однако в этом экземпляре нет никакого фактического финала, ПОСТАВЛЯЮТ в сам почтовый ящик. Вышеупомянутое является заключительной частью журнала отслеживания, который обычно указывал бы, когда "ПОСТАВЛЯЮТ" к почтовому ящику, но никогда не получал это далеко.
Какие-либо идеи о том, как определить то, что произошло здесь на том, почему почта была отброшена перед электронной почтой, были обеспечены самому почтовому ящику?
Проверяли ли вы журнал приложений в средстве просмотра событий примерно в то время, когда сообщение было отброшено, чтобы узнать, есть ли какие-либо признаки того, что произошло?
Имя журнала: Приложение
Категория задачи: SmtpReceive
Также почему вы получаете почтовый ящик с почти полным предупреждением извне? Это может быть фильтр спама Exchange, отбрасывающий сообщение.
Также, если вы используете группу обеспечения доступности баз данных, убедитесь, что вы отметили «Доставку» на активном сервере базы данных, а не на пассивном сервере. Я полагаю, что на пассивном сервере будут отображаться сообщения «ПОЛУЧИТЬ» и «ОТПРАВИТЬ», но не «ДОСТАВКА».
Отслеживание сообщений в логах Exchange 2013 — быстро и легко!
Огромная масштабируемость системы Exchange кроме всех своих преимуществ, несет в себе и большие минусы. Один из таких минусов — сложность в отслеживании почтовых сообщений в логах. Ведь имея несколько транспортных серверов (не дай Бог еще и объединенных в DAG), мы получаем ситуацию, когда письмо проходит через все сервера и оставляет свой след в логах на каждом.
Сейчас я постараюсь хотя бы частично помочь в том, как более-менее результативно отслеживать логи прохождения сообщений.
Принципиальную схему пути сообщения (Exchange 2013 Mail Flow / Transport Pipeline) описывает данный рисунок:
Отслеживание писем в Exchange 2013
Мой подход к отслеживанию сообщений в Exchange вот такой:
- Получаем ID нужного письма с помощью Get-MessageTrackingLog.
- С помощью Log Parser 2.2 получаем детальный лог по конкретному письму.
Почему нельзя использовать только Get-MessageTrackingLog (ведь он умеет достаточно быстро искать по логам сразу на нескольких серверах)? У Get-MessageTrackingLog есть только одна неприятная особенность: в результатах он отдает записи из логов с некоторой временной меткой (TimeStamp), так вот коммандлет отдает эту метку с точностью до секунды, хотя в текстовых логах хранится время с точностью до тысячной секунды. Так вот многие операции происходят в течение одной единственной секунды, и из-за этого невозможно выстроить хронологию событий.
Именно поэтому мы будем обрабатывать логи через Log Parser 2.2. Это унивесальный парсер логов от Microsoft, который работает с языком SQL в качестве запросов.
Ищем письма с помощью Get-MessageTrackingLog
В составе Exchange 2013 есть замечательный коммандлет Get-MessageTrackingLog. Он позволяет найти нужное сообщение с использованием параметров в качестве фильтра. Самое подробное описание фильтрующих параметров смотрите вот тут: https://technet.microsoft.com/en-us/library/aa997573(v=exchg.150).aspx.
Вот пример, как использовать Get-MessageTrackingLog для поиска MessageId:
Скопируем MessageId и двигаемся дальше.
Пользуемся Log Parser 2.2 и Log Parser Studio
Во-первых нам нужно установить Log Parser 2.2 и Log Parser Studio (GUI для Log Parser 2.2). Вот ссылки:
-
— Log Parser 2.2 — Log Parser Studio
Устанавливаем обе программы и запускаем Log Parser Studio — LPS.exe.
Обратите внимание: указываем логи сразу с двух серверов (если их два)!
Далее создаем новый запрос и устанавливаем тип лог-файлов — EELLOG. Сортировка — по времени.
Выполняем запрос и получаем результат:
Анализ лога
Теперь вы можете просмотреть, какой путь прошло письмо, и возможно, найдете причину сбоев. В большинстве случаев вам понадобятся следующие поля:
- client-ip
- client-hostname
- server-ip
- server-hostname
- connector-id
- source
- event-id
Последние два упомянутых поля source и event-id — говорят о том, какие действия выполнялись с письмом. Помощь в анализе этих полей вы можете получить в этой статье:
Для вашего и своего удобства привожу самые полезные сведения тут.
Возможные значения поля event-id
AGENTINFO
Это событие используется агентами транспорта для журналирования пользовательских данных.
BADMAIL
Сообщение отправлено каталогом раскладки или каталогом преобразования и не может быть доставлено и возвращено.
CLIENTSUBMISSION
Сообщение было отправлено из папки «Исходящие» почтового ящика.
DEFER
Доставка сообщения отложена.
DELIVER
Сообщение было доставлено в локальный почтовый ящик.
DSN
Создано уведомление о доставке (также называемое сообщением возврата или отчетом о недоставке).
DROP
Сообщение было отклонено без уведомления о доставке (также называемого сообщением возврата или отчетом о недоставке). Например:
сообщения о выполненных запросах для утверждения;
нежелательные сообщения, удаленные автоматически без отчета о недоставке.
DUPLICATEDELIVER
Сообщение было доставлено получателю повторно. Повторная доставка сообщений может происходить в том случае, если получатель входит в несколько вложенных групп рассылки. Банк данных обнаруживает и удаляет дубликаты сообщений.
DUPLICATEEXPAND
При расширении группы рассылки обнаружен повторяющийся получатель.
DUPLICATEREDIRECT
Альтернативный получатель сообщения уже являлся получателем.
EXPAND
Была расширена группа рассылки.
FAIL
Не удается доставить сообщение. Источники: SMTP, DNS, QUEUE и ROUTING.
HADISCARD
Теневое сообщение было отвергнуто, после того как основная копия была доставлена на следующий узел. Подробнее см. в разделе Теневая избыточность.
HARECEIVE
Теневое сообщение было получено сервером в локальной группе обеспечения доступности баз данных или на сайте Active Directory.
HAREDIRECT
Создано теневое сообщение.
HAREDIRECTFAIL
Не удалось создать теневое сообщение. Сведения сохранены в поле source-context.
INITMESSAGECREATED
Сообщение отправлено контролируемому получателю, поэтому оно отправлено в почтовый ящик вынесения решения для утверждения. Подробнее см. в разделе Управление утверждением сообщений.
LOAD
Сообщение успешно загружено при загрузке.
MODERATIONEXPIRE
Модератор контролируемого получателя не утвердил и не отклонил сообщение, поэтому для него истек срок ожидания. Дополнительные сведения о контролируемых получателях см. в разделе Управление утверждением сообщений.
MODERATORAPPROVE
Модератор контролируемого получателя утвердил сообщение, поэтому оно было доставлено контролируемому получателю.
MODERATORREJECT
Модератор контролируемого получателя отклонил сообщение, поэтому оно не было доставлено контролируемому получателю.
MODERATORSALLNDR
Все запросы для утверждения, отправленные всем модераторам контролируемого получателя, не могли быть доставлены и привели к отправке отчетов о недоставке (также называемых сообщениями возврата).
NOTIFYMAPI
Сообщение было обнаружено в папке «Исходящие» почтового ящика на локальном сервере.
NOTIFYSHADOW
Сообщение было обнаружено в папке «Исходящие» почтового ящика на локальном сервере, и необходимо создать теневую копию сообщения.
POISONMESSAGE
Сообщение помещено в очередь сообщений о сбое или удалено из нее.
PROCESS
Сообщение успешно обработано.
RECEIVE
Сообщение было получено компонентом получения протокола SMTP службы транспорта или из каталога раскладки или каталога преобразования (источник: SMTP ), или сообщение было отправлено из почтового ящика в службу отправки почтовых ящиков (источник: STOREDRIVER ).
REDIRECT
Сообщение было перенаправлено другому получателю в результате поиска в Active Directory.
RESOLVE
В результате поиска в Active Directory для получателей сообщения был найден другой адрес электронной почты.
RESUBMIT
Сообщение было автоматически повторно отправлено из сети безопасности. Подробнее см. в разделе Система безопасности.
RESUBMITDEFER
Сообщение, повторно отправленное из сети безопасности, было отложено.
RESUBMITFAIL
Сообщение, повторно отправленное из сети безопасности, не удалось отправить.
SEND
Сообщение было отправлено протоколом SMTP между службами транспорта.
SUBMIT
Служба отправки почтовых ящиков успешно передала сообщение службе транспорта. Для событий SUBMIT свойство source-context содержит следующие данные:
MDB GUID базы данных почтовых ящиков.
Mailbox GUID почтового ящика.
Event Порядковый номер события.
MessageClass Тип сообщения. Например, IPM.Note .
CreationTime Дата и время отправки сообщения.
ClientType. Примеры: User , OWA и ActiveSync .
SUBMITDEFER
Передача сообщения из службы доставки почты в почтовый ящик в службу транспорта была отложена.
SUBMITFAIL
Передача сообщения из службы доставки почты в почтовый ящик в службу транспорта не была выполнена.
SUPPRESSED
Передача сообщения была отменена.
THROTTLE
Сообщение было отрегулировано.
TRANSFER
В результате преобразования содержимого, ограничения числа получателей или работы агентов получатели были перемещены в сообщение с ветвлением. Источники: ROUTING или QUEUE.
Возможные значения поля source
ADMIN
Источник события был введен пользователем. Например, администратор использовал средство просмотра, чтобы удалить сообщение, или отправил файлы сообщений с помощью каталога воспроизведения.
AGENT
Источником события был агент транспорта.
APPROVAL
Источником события была платформа утверждения, используемая для контролируемых получателей. Подробнее см. в разделе Управление утверждением сообщений.
BOOTLOADER
Источником события были необработанные сообщения, которые присутствовали на сервере на момент загрузки. Это относится к типу событий LOAD.
DNS
Источником события было DNS.
DSN
Источником события было уведомление о доставке (также называемое сообщением возврата или отчетом о недоставке).
GATEWAY
Источником события был внешний соединитель. Подробнее см. в разделе Внешние соединители.
MAILBOXRULE
Источником события было правило для папки «Входящие». Дополнительные сведения см. в статье Правила для папки «Входящие» в Outlook Web App.
MEETINGMESSAGEPROCESSOR
Источником события был обработчик сообщения о собрании, который обновляет календари в соответствии с обновлениями собрания.
ORAR
Источником события был альтернативный получатель, запрошенный отправителем (ORAR). Вы можете включить или отключить поддержку ORAR на получающих соединителях, используя параметр OrarEnabled в командлете New-ReceiveConnector или Set-ReceiveConnector.
PICKUP
Источником события был каталог раскладки. Подробнее см. в разделе Каталог раскладки и каталог преобразования.
POISONMESSAGE
Источником события был идентификатор сообщения о сбое. Дополнительные сведения о сообщениях о сбое и очереди сообщений о сбое см. в разделе Queues and messages in queues
PUBLICFOLDER
Источником события была общедоступная папка, поддерживающая почту.
QUEUE
Источником события была очередь.
REDUNDANCY
Источником события было избыточное теневое копирование. Подробнее см. в разделе Теневая избыточность.
ROUTING
Источником события был компонент разрешения маршрутизации классификатора в службе транспорта.
SAFETYNET
Источником события была сеть безопасности. Подробнее см. в разделе Система безопасности.
SMTP
Сообщение было отправлено компонентом отправки или получения SMTP службы транспорта.
STOREDRIVER
Источником события была MAPI-отправка из почтового ящика на локальном сервере.
- Last updated on 12 июля 2016.
- Просмотров: 53519
- Предыдущий: Windows 7/2008/R2/8/8.1 всегда загружается в режим восстановления / recovery mode Назад
- Следующий: Массовая запись в базу MS SQL скриптом на Powershell Вперед
Привет (давайте «на ты :-)»)!
К сожалению, уже не могу на 100% точно сказать, т.к. уже не работаю в компании, где был Exchange :).
Но на 99.999% — это особенность работы отказоустойчивости транспортных серверов. К сожалению, у меня на скриншоте замазаны поля client-ip и server-ip, но практически уверен, что там указаны ip-адреса двух моих (или ваших:)) mailbox-серверов.
Кстати, если обратите внимание, то время событий SMTP -SEND и STOREDRIVER-DELIVER одинаковое с точностью до милисекунды.
Related Articles
Поиск и\или удаление писем и сообщений в почтовых ящиках в Exchange 2010/2013/2016
19 октября 2016
Отказоустойчивость серверов клиентского доступа в Exchange 2013 (Client Access Server, CAS)
Как дублировать Receive Connector (принимающий коннектор) в Exchange 2013 на другой сервер
Перемещаем логи Exchange 2013 из папок по умолчанию с помощью Powershell
In order to provide you with the best online experience this website uses cookies.
By using our website, you agree to our use of cookies. Learn more
Политика использования файлов cookies
Политика использования файлов cookies для B-blog.info
Это политика в отношении файлов cookie для B-blog.info, доступная по адресу https://b-blog.info. Она является частью общей Политика конфиденциальности.
Что такое файлы cookie
Как это принято почти на всех профессиональных веб-сайтах, этот сайт использует файлы cookie, представляющие собой крошечные файлы, которые загружаются на ваш компьютер для улучшения вашего опыта. На этой странице описывается, какую информацию они собирают, как мы ее используем и почему нам иногда нужно хранить эти файлы cookie. Мы также расскажем, как вы можете предотвратить сохранение этих файлов cookie, однако это может привести к понижению или «нарушению» определенных элементов функциональности сайтов.
Как мы используем файлы cookie
Мы используем файлы cookie по целому ряду причин, описанных ниже. К сожалению, в большинстве случаев не существует стандартных вариантов отключения файлов cookie без полного отключения функций и функций, которые они добавляют на этот сайт. Рекомендуется оставить все файлы cookie, если вы не уверены, нужны они вам или нет в случае, если они используются для предоставления услуги, которой вы пользуетесь.
Отключение файлов cookie
Вы можете запретить установку файлов cookie, изменив настройки своего браузера (как это сделать, см. Справку браузера). Имейте в виду, что отключение файлов cookie повлияет на функциональность этого и многих других веб-сайтов, которые вы посещаете. Отключение файлов cookie обычно приводит к отключению определенных функций и функций этого сайта. Поэтому рекомендуется не отключать файлы cookie.
Файлы cookie, которые мы устанавливаем
Файлы cookie, связанные с аккаунтом
Если вы создадите у нас учетную запись, мы будем использовать файлы cookie для управления процессом регистрации и общего администрирования. Эти файлы cookie обычно удаляются, когда вы выходите из системы, однако в некоторых случаях они могут сохраняться впоследствии, чтобы запомнить ваши настройки сайта при выходе из системы.
Файлы cookie, связанные с входом в систему
Мы используем файлы cookie, когда вы входите в систему, чтобы запомнить этот факт. Это избавляет вас от необходимости входить в систему каждый раз, когда вы посещаете новую страницу. Эти файлы cookie обычно удаляются или очищаются, когда вы выходите из системы, чтобы вы могли получить доступ к ограниченным функциям и областям только после входа в систему.
Файлы cookie, связанные с формами
Когда вы отправляете данные через форму, такую как те, которые находятся на страницах контактов или формах комментариев, файлы cookie могут быть настроены на запоминание ваших данных пользователя для будущей переписки.
Сторонние файлы cookie
В некоторых особых случаях мы также используем файлы cookie, предоставленные доверенными третьими лицами. В следующем разделе подробно описано, с какими сторонними файлами cookie вы можете столкнуться на этом сайте.
На этом сайте используется Google Analytics, одно из самых распространенных и надежных аналитических решений в Интернете, помогающее нам понять, как вы используете сайт, и способы, которыми мы можем улучшить ваш опыт. Эти файлы cookie могут отслеживать такие вещи, как время, которое вы проводите на сайте, и страницы, которые вы посещаете, чтобы мы могли продолжать создавать привлекательный контент.
Дополнительную информацию о файлах cookie Google Analytics см. на официальной странице Google Analytics.
Сторонняя аналитика используется для отслеживания и оценки использования этого сайта, чтобы мы могли продолжать создавать привлекательный контент. Эти файлы cookie могут отслеживать такие вещи, как время, которое вы проводите на сайте или страницах, которые вы посещаете, что помогает нам понять, как мы можем улучшить сайт для вас.
Время от времени мы тестируем новые функции и вносим небольшие изменения в способ доставки сайта. Когда мы все еще тестируем новые функции, эти файлы cookie могут использоваться для обеспечения стабильного взаимодействия с сайтом и понимания того, какие оптимизации наши пользователи ценят больше всего.
Поскольку мы продаем продукты, для нас важно понимать статистику о том, сколько посетителей нашего сайта действительно совершают покупку, и именно такие данные будут отслеживаться этими файлами cookie. Это важно для вас, так как это означает, что мы можем делать точные бизнес-прогнозы, которые позволяют нам отслеживать наши затраты на рекламу и продукты, чтобы обеспечить наилучшую возможную цену.
Служба Google AdSense, которую мы используем для показа рекламы, использует файл cookie DoubleClick для показа более релевантной рекламы в Интернете и ограничения количества показов данной рекламы вам.
Дополнительную информацию о Google AdSense см. в официальном разделе часто задаваемых вопросов о конфиденциальности Google AdSense.
Мы используем рекламу, чтобы компенсировать расходы на содержание этого сайта и обеспечить финансирование его дальнейшего развития. Файлы cookie поведенческой рекламы, используемые этим сайтом, предназначены для того, чтобы мы по возможности показывали вам наиболее релевантную рекламу, анонимно отслеживая ваши интересы и представляя похожие вещи, которые могут вас заинтересовать.
Несколько партнеров размещают рекламу от нашего имени, а файлы cookie для отслеживания аффилированных лиц просто позволяют нам видеть, заходили ли наши клиенты на сайт через один из наших партнерских сайтов, чтобы мы могли соответствующим образом кредитовать их и, где это применимо, позволять нашим аффилированным партнерам предоставлять какие-либо бонусы. что они могут предоставить вам для совершения покупки.
Мы также используем кнопки социальных сетей и/или плагины на этом сайте, которые позволяют вам подключаться к вашей социальной сети различными способами. Чтобы они работали, следующие сайты социальных сетей (Facebook, Twitter, LinkedIn, Reddit, Pinterest) будут устанавливать файлы cookie через наш сайт, которые могут использоваться для улучшения вашего профиля на их сайте или добавления данных, которые они хранят, для различных целей, изложенных в их соответствующие политики конфиденциальности.
Дополнительная информация
Надеюсь, это прояснило для вас некоторые вещи, и, как упоминалось ранее, если есть что-то, в чем вы не уверены, нужно вам это или нет, обычно безопаснее оставить файлы cookie включенными, если они взаимодействуют с одной из функций, которые вы используете на наш сайт.
Для получения более общей информации о файлах cookie см. статью о политике использования файлов cookie.
Однако, если вам все еще нужна дополнительная информация, вы можете связаться с нами одним из наших предпочтительных способов связи: