Как именно работает аутентификация SMTP?

В вашем случае аутентификация, похоже, вообще не требуется.

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

Помимо требования о том, что какая-то разновидность аутентификации (явная или неявная) должна требоваться перед ретрансляцией (отправкой почты в пункты назначения за пределами тех, которые сервер обрабатывает сам), не существует большого консенсуса относительно того, что именно следует применять. Большинство серверов требуют явного входа перед принятием почты, представленной как исходящая от адресата, для которого они являются конечным пунктом назначения. Большинство серверов требуют, чтобы конверт совпадал со списком разрешенных псевдонимов для каждого логина. Некоторые серверы будут применять дополнительные ограничения к заголовку адреса, возможно, даже к отображаемому имени.

Какой уровень ограничений является подходящим, зависит от вашего окружения и от того, какие другие методы вы применяете для а) борьбы и б) диагностики потенциальных злоупотреблений.

Рекомендации:

1. определите и проверьте список систем, уполномоченных отправлять от вашего имени, и которым доверено применять ограничения: SPF"
2. потребовать, чтобы вся передаваемая почта отправлялась только после явной аутентификации; это означает прекратить предоставление "open relay"

Как лучше всего это сделать, зависит от используемого вами программного обеспечения и пользователей почты (которые в настоящее время зависят от в основном неограниченной конфигурации) и, таким образом, выходит за рамки того, что я могу изложить в одном ответе, но чтобы было более понятно:

Я твердо убежден, что в описанном вами случае: любой может использовать любой адрес источника как в конверте, так и в заголовках - безрассуден и будет (и, возможно, уже был) использован для обмана вашей компании и других.

Весь смысл аутентификации заключается в авторизации вызывающего абонента на основе результатов аутентификации. После аутентификации сервер знает, кто вы, и может предоставить вам все дополнительные услуги. Для электронной почты это будет ретрансляция вашей почты на внешние серверы, даже если она не будет ретранслироваться для неаутентифицированных клиентов. Обратите внимание, что ваши первые два примера не были предназначены для ретрансляции, поэтому сервер принимал почту; так вообще выглядит диалог между двумя серверами.

Я часто настраиваю серверы так, чтобы они также проверяли, разрешено ли аутентифицированному пользователю использовать этот адрес отправителя конверта (MAIL FROM). Таким образом, вы не сможете отправлять внешнюю почту с отправителем конверта, установленным на адрес электронной почты вашего начальника, даже если вы прошли аутентификацию.

Для SMTP определены три порта. Хорошо известный порт 25 первоначально использовался для всей ретрансляции, а затем для отправки от почтовых пользовательских агентов (MUA); теперь его рекомендуемое использование - только ретрансляция (связь между серверами). Он часто отключается на уровне провайдера, поэтому пользователи даже не могут подключиться к внешнему порту 25, это помогает предотвратить спам с зараженных компьютеров. Поскольку MUA на этом порте не ожидается, аутентификация на нем часто отключается.

Другой порт - 587; он определяется как отправка SMTP и это порт, который используют клиенты MUA. Он начинается как обычный текст, но после команды его можно обновить до STARTTLS. Это обеспечивает более широкую поддержку и некоторое автоматическое обнаружение. Этот порт часто использует аутентификацию.

Третий порт, 465, - это SMTPS, он также предназначен для отправки, но ожидается, что клиенты сначала инициализируют TLS, а затем начнут сеанс SMTP внутри него. Он также ожидает, что MUA аутентифицируют себя.

Аутентификация SMTP определена в RFC 4954 и выполняется следующим образом:

I. Он поддерживается только для ESMTP, т.е. является расширением; исходный SMTP не имеет аутентификации. Для инициализации вы должны подключиться к серверу и выдать ESMTP HELLO:

   EHLO my.host.name

II. Удаленный сервер покажет расширенный ответ, в котором перечислены расширения, которые он поддерживает на данном этапе протокола . Теперь нас интересуют расширения AUTH и STARTTLS. AUTH может быть изначально недоступен (т.е. нет строки с AUTH), но если есть поддержка STARTTLS, вы можете ввести команду STARTTLS и установить сеанс TLS, тогда может появиться AUTH. Обратите внимание, вы не сможете использовать STARTTLS в сеансе telnet ; чтобы проверить, каково это внутри зашифрованного туннеля, просто используйте инструмент openssl s_client . В общем, если AUTH есть в списке, за ним будет следовать список доступных методов аутентификации:

250-AUTH DIGEST-MD5 LOGIN CRAM-MD5 NTLM

III. Затем клиент выбирает метод аутентификации и продолжает:

AUTH LOGIN

Для метода LOGIN сервер ожидает две строки, имя пользователя и пароль. Сначала он спрашивает:

334 VXNlcm5hbWU6

Если вы декодируете эту строку base64, это будет слово «Имя пользователя».Вы отвечаете, используя имя пользователя, закодированное в base64, а он отвечает другой строкой:

334 UGFzc3dvcmQ6

Это слово «Пароль» в base64, и теперь сервер ожидает ваш пароль в виде обычного текста. Опять же, на этом этапе вы отвечаете паролем в кодировке base64.

IV. Сервер скажет, прошла ли аутентификация успешно или нет:

535 5.7.8 Error: authentication failed: authentication failure
235 2.7.0 Authentication successful

После этого вы продолжите сеанс SMTP.

В других методах аутентификации используются другие процедуры. У каждого из них есть свои достоинства и недостатки. LOGIN и PLAIN требуют, чтобы вы отправляли пароль в виде открытого текста, что должно выполняться только через STARTTLS, но сервер может хранить зашифрованные пароли, а не в виде обычного текста. С механизмом CRAM-MD5 сервер ставит перед вами задачу, и вы должны рассчитать правильный ответ, чтобы доказать, что вы знаете пароль, без отправки его в виде обычного текста (или в любой обратимой кодировке) по сети. Он устойчив к перехвату через незашифрованное соединение, но требует, чтобы сервер хранил пароли в виде обычного текста. ДАЙДЖЕСТ-МД5 похож. В целом, SRP-6 считается наиболее безопасным механизмом на основе паролей, но его сложно реализовать, и он требует довольно сложных вычислений с обеих сторон, поэтому широко не используется.

Эти методы являются подключаемыми. Вся процедура передается в библиотеку SASL, которая реализует конкретные процедуры. В моем примере библиотека SASL на сервере либо не поддерживает какой-либо вариант SRP, либо была отключена в конфигурации.

Нет, файлы Azure не предоставляют способа ограничения доступа к загрузке определенного файла, если у пользователя есть ключ или маркер SaS для учетной записи места хранения (или доступ к нему через ML Studio), то он сможет загрузить файл.

В вашем случае аутентификация вообще не требуется.

Проверка подлинности SMTP работает путь она настраивается. Исторически, программное обеспечение электронной почты поставлялось только с формальными ограничениями на то, какие адреса источника и назначения могут использовать даже неаутентифицированные третьи стороны.

Помимо требования, что какой-то вид аутентификации (явной или неявной) должен требоваться до ретрансляции (отправка почты для адресатов вне того, что сервер обрабатывает сам), не существует большого консенсуса относительно того, что принудительно применять. Большинству серверов потребуется явное имя входа, прежде чем принимать почту, представляемую как исходящую из пункта назначения, для которого они являются конечным пунктом назначения. Для большинства серверов требуется, чтобы конверт соответствовал списку разрешенных псевдонимов для каждого входа в систему. Некоторые серверы будут применять дополнительные ограничения к заголовку из адреса, возможно, даже отображаемого имени.

Какой уровень ограничений подходит, зависит от вашей среды и от того, какие другие методы вы применяете для a) борьбы и b) диагностики возможных злоупотреблений.

Рекомендации:

1. определите и проверьте список систем, авторизованных для отправки от вашего имени, и доверенных для применения ограничений: ключевое слово поиска по типичному способу: « SPF »
2. требуют, чтобы вся пересылаемая почта могла быть отправлена только после явной аутентификации; это означает, что прекратить предоставление « open relay »

Как лучше всего это сделать, во многом зависит от используемого вами программного обеспечения и пользователей почты (что в настоящее время возможно зависит от в основном неограниченной конфигурации) и, таким образом, выходит за рамки того, что я могу поставить в одном ответе, но сделать больше вещи обильно ясно:

Я твердо верю, что случай, который вы описываете: любой может использовать любой исходный адрес как в конверте, так и в заголовках - опрометчивый и будет (и, возможно, уже был) злоупотреблен, чтобы обмануть вашу компанию и других.

Почтовые серверы обычно имеют очень гибкие возможности настройки. Можно определить набор IP-адресов или сетей, для которых аутентификация не требуется (например, в Postfix это обычно называется параметром «mynetworks»), а для всех остальных IP-адресов сервер может потребовать аутентификации. Или соединения с других адресов могут быть полностью отклонены без учета возможной аутентификации.

В сети компании, как правило, для аутентификации клиентов, подключающихся из сети компании, не требуется. Наверное, это твое дело.

В настоящее время довольно распространенной конфигурацией является то, что порт 25 (который, вероятно, использовался в тестах) используется только для входящей почты, т.е..для почты в домен, которую должен обслуживать данный сервер. В вашем случае SMTP-сервер компании предназначен для обслуживания почты для домена company.com , поэтому он будет принимать ее без какой-либо аутентификации, так как кто-либо извне может отправлять почту на someone@company.com , а SMTP-серверы не аутентифицируются друг другу при отправке почты - это не имело бы смысла. Однако при попытке отправить через порт 25 почту в любой другой домен, кроме company.com (который называется почтой , ретранслирующей ), это сообщение, вероятно, будет полностью отклонено.

Для ретрансляции почты существует другой порт, 587, и обычно почтовые серверы настраиваются так, чтобы аутентификация на 587 порта была обязательной. Часто TLS-шифрование соединения является обязательным для этого порта.