Функции серверной задачи Mail Router и база MAIL.BOX
Задача Mail Router должна выполняться на каждом сервере Notes, который используется как почтовый сервер. Router не имеет никаких собственных протоколов передачи сообщений. Он использует обычные средства работы с базами данных Notes, когда извлекает документы сообщений из одних баз и записывает эти документы в другие базы.
При выборе базы данных, в которую должен быть записан документ сообщения, Router использует информацию из предопределенных полей этого сообщения. В документе сообщения всегда присутствуют поля SendTo (список адресов получателей сообщения)
и From (адрес отправителя). Кроме того, могут иметься поля CopyTo (список адресов получателей копии сообщения), BlindCopyTo (список адресов получателей "слепой" копии сообщения), DeliveryPriority (приоритет доставки), DeliveryReport (возвращать ли уведомление о доставке), ReturnReceipt (возвращать ли уведомление о прочтении) и целый ряд других. Чтобы "увидеть" эти поля, исследуйте в вашем почтовом ящике любое входящее сообщение, выбрав в окне свойств документа сообщения закладку Fields.
Рис. 7.1 Окно свойств документа сообщения, закладка Fields
Задача Router исполняет следующие функции:
· периодический просмотр локальной базы MAIL.BOX на предмет появления в ней новых сообщений;
· доставка сообщений пользователям, почтовые ящики которых находятся локально на сервере, где функционирует задача Router;
· решение задачи маршрутизации и передача сообщения в базу MAIL.BOX другого сервера.
Обратите внимание на следующие важные моменты.
· Router может только передавать сообщения на другой сервер. При этом он связывается с этим сервером, открывает на нем базу MAIL.BOX и записывает в нее сообщения. Router не занимается приемом сообщений с другого сервера или от пользователя. В него "не заложена" возможность вызывать другой сервер для того, чтобы "забрать предназначенную себе почту". Однако в некоторых случаях Router способен воспользоваться соединением, установленным с "его" сервером по инициативе другого сервера, чтобы передать "свои" сообщения на установивший соединение сервер.
· Router не использует задачу Replicator для выполнения своих функций.
· Каждая база MAIL.BOX - "собственность и забота" одного Router. Обычно любой может помещать сообщения в MAIL.BOX. Но только Router, выполняющийся на сервере, на котором находится MAIL.BOX, может "вынимать" из него сообщения. Стандартные установки в списке управления доступом MAIL.BOX:
Depositor для -Default- и Manager для сервера, на котором выполняется Router.
· Сообщения, приходящие пользователю извне, помещаются задачей Router в почтовый ящик пользователя на сервере. Исходящие сообщения пользователя, активный почтовый ящик которого находится на сервере (режим On Server), сразу записываются Mailer-ом в MAIL.BOX на сервере. Исходящие сообщения от пользователя, активный почтовый ящик которого находится на станции (режим Local) сначала записываются Mailer-ом в MAIL.BOX на станции, а затем, когда станция связывается с почтовым сервером, передаются Mailer-ом в MAIL.BOX на сервере. Пользователь, работающий в режиме Local, использует механизм репликаций, реализуемый программным обеспечением станции, чтобы обмениваться документами между своим локальным почтовым ящиком и его репликой на сервере. При этом из реплики на сервере в почтовый ящик на станции передаются пришедшие пользователю новые сообщения, а в обратную сторону, если это не запрещено в репликационных установках, копии отправленных пользователем сообщений.
Рис. 7.2 Основные положения почтовой системы Notes
В работе задачи Router прослеживаются два цикла.
· Цикл доставки новой почты. Период выполнения цикла очень короток - около одной минуты. Router обнаруживает появление новой почты, анализируя время модификации файла MAIL.BOX. Такая проверка происходит быстро и с малыми вычислительными затратами, оттого и может выполняется столь часто. Как только Router обнаруживает изменение времени модификации файла MAIL.BOX, он выполняет просмотр базы MAIL.BOX, чтобы найти новые сообщения и организовать их доставку своими подпроцессами.
· Цикл повторной доставки ранее не доставленной почты. Период выполнения цикла более длинный - ориентировочно 10-30 минут. Router выполняет просмотр базы MAIL.BOX, чтобы найти ранее не доставленные сообщения и организовать их повторную доставку своими подпроцессами.
MAIL.BOX используется для временного хранения исходящих (со станции) или доставляемых (на сервер) сообщений. MAIL.BOX автоматически создается на сервере при первом запуске задачи Router. MAIL.BOX автоматически создается на станции при первом выборе режима Local в документе Location и сохранении этого документа.
MAIL.BOX станции используется только в режиме Local. Именно в него Mailer - отвечающее за доставку почты программное обеспечение станции - помещает отправленные пользователем сообщения - исходящую со станции почту. В режиме On Server Mailer станции помещает отправленные пользователем сообщения непосредственно в MAIL.BOX на сервере.
Для сервера MAIL.BOX является местом временного хранения сообщений, поступивших на сервер и ожидающих дальнейшей доставки серверной задачей Router. Здесь же может находиться так называемая "мертвая" почта (dead mail) - сообщения, которые не удалось доставить в течение суток, а по истечении этого срока вернуть отправителю уведомление об их недоставке (Delivery Failure Report). Одни сутки - только значение по умолчанию, его можно изменить, задав в файле NOTES.INI переменную MailTimeout=<число дней> или MailTimeoutMinutes=<число минут>. Заметим, что в Notes версий 3.х "мертвая" почта трактовалось "уже" - только как сообщения, которые не удалось доставить в течение суток - и оттого "встречалась чаще".
В MAIL.BOX версий 4.х всего один вид Mail. Он "показывает" всю почту, ожидающую доставки, отсортированную по времени появления. "Мертвые" письма (Dead letters) отображаются в этом виде в отдельной категории и отмечаются пиктограммой красного цвета.
Рис. 7.3 В MAIL.BOX имеется два "мертвых" письма, а ожидающих отправки нет
Чтобы повторно попытаться отправить "мертвую" почту, нужно выполнить агента Release Dead Messages.
Повторим, что причиной появления "мертвой" почты является невозможность доставить сообщение адресату в течение 24-х часов из-за отсутствия связи или неработоспособности вызываемого сервера, а затем, по аналогичным причинам, невозможность вернуть отправителю сообщения уведомление о недоставке. Ошибка в имени получателя или домена получателя, а также возможность вернуть уведомление о недоставке из-за отсутствия связи или неработоспособности вызываемого сервера в течение 24-х часов не влекут появления "мертвой" почты - в этом случае отправитель получает уведомление о недоставке почти немедленно (Рис. 7.4) или через некоторое время (Рис. 7.5, Рис. 7.6).
Рис. 7.4 Уведомление о недоставке - почтовый сервер отправителя сразу выяснил, что из текущего домена нет пути в домен X
Рис. 7.5 Уведомление о недоставке - путь из домена отправителя (InterTrustCorp, г. Москва) в домен получателя (Kiev, г. Киев) имеется, сообщение доставляется на сервер в домене Kiev, но там выясняется отсутствие получателя. Поскольку между серверами InterTrust/InterTrustCorp, MOSCOW_ISLAND и Viaduk/Kiev/UA используются модемные соединения, с момента отправки сообщения до получения уведомления о недоставке проходит некоторое время
Рис. 7.6 Уведомление о недоставке, возвращенное на сообщение, которое серверу не удалось доставить в течение суток, хотя все необходимые документы в адресной книге присутствовали
