3. Продолжение работы
3.1. Влияние на пользовательские агенты SMTP и конечных пользователей
Хотя этот документ посвящен агентам доставки почты MTA и содержит рекомендации для них, он оказывает некоторое влияние на работу пользовательских агентов UA (User Agents — обычные почтовые программы). Агенты UA:
- Читают сообщения из почтовых ящиков и выводят их на экран. Для доступа к почте обычно используются протоколы POP, IMAP или NFS.
- Читает пользовательский ввод с клавиатуры и передает его агенту MTA для доставки в качестве почтового сообщения. Для этого обычно используется протокол SMTP (т. е., тот же протокол, который применяется для обмена почтой между MTA).
Когда агенты MTA начали использовать различные антиспамовые фильтры, как описано выше, агенты UA на переносных компьютерах стали получать сообщения типа "Relaying Denied" просто потому, что они использовали адреса IP из неизвестного диапазона или эти адреса преобразовывались в неизвестные имена FQDN.
Типичным случаем получения отказа от трансляции является использование переносного компьютера в менеджером по продажам, находящимся в командировке или даже делегатом на конференции IETF. Менеджер вероятно подключается к ближайшему ISP и получает адрес IP из пула этого провайдера, а делегат IETF будет использовать адрес IP из выделенного для таких подключений блока. В обоих случаях будут возникать проблемы при работе почтовой программы (UA — например, pine, Netscape, Eudora), которая будет пытаться отправить почту через «домашний» агент MTA (например, SMTPSERVER= mail.home.example), но пока mail.home.example не будет обновлен для приема почты с этого (временного) адреса IP, он будет возвращать код "Relaying Denied" и отказывать в приеме почты.
Для решения проблемы можно просто добавить временные адреса IP в список сетей, из которых принимается почта для трансляции, на mail.home.example. Это создает некоторый незначительный риск использования добавленных адресов спамерами, подключающимися к сети с адресами из добавленных блоков (например, через того же ISP во время нахождения менеджера в командировке). Однако риск достаточно мал, если не открывать постоянную трансляцию со всего мира и вести наблюдение за журнальными файлами транслятора с целью прекращения доступа из временного блока после того, как в этом отпадет необходимость.
Другим вариантом будет использование менеджером почтового транслятора местного провайдера, если такой транслятор предоставляется. Для использования этого метода нужно изменить SMTP-SERVER= в UA на переносном компьютере, что может оказаться слишком сложной задачей для менеджера.
Корректным способом решения проблемы было бы использование другого протокола между UA и MTA.
Хотя отдельного протокола подачи почтовых сообщений не существует, недавно был определено профиль SMTP для решения этой задачи — "Message Submission" [9].
Возможно также при использовании SMTP Authentication [10] применять Authenticated SMTP в качестве протокола для обмена между UA и домашним агентом MTA (не имеет значения рассматривать этот протокол как новый или тот же самый SMTP).
Это добавляет один элемент в алгоритм трансляции, предложенный в параграфе 2.1:
- + If "SMTP Authenticated" then accept to Relay.