Return path что это

Все отскоки, которые происходят во время сеанса SMTP, должны возвращаться к адресу Return-Path. Некоторые серверы могут принимать всю электронную почту, а затем ставить ее в очередь локально, пока у нее не появится свободная нить для доставки ее в почтовый ящик получателя. Если получатель не существует, он должен вернуть его обратно к записанному значению Return-Path.

Обратите внимание, что не все почтовые серверы подчиняются этому правилу; Некоторые почтовые серверы возвращают его обратно на адрес FROM.

Заголовок Reply-To добавляется отправителем (или программным обеспечением отправителя). Это где все человеческие ответы должны быть рассмотрены тоже. По сути, когда пользователь нажимает «ответить», значение Reply-To должно быть значением, используемым в качестве получателя вновь составленного электронного письма. Значение Reply-To не должно использоваться никаким сервером. Он предназначен только для клиентского использования (MUA).

Однако, как вы можете сказать, не все почтовые серверы подчиняются стандартам или рекомендациям RFC.

Надеюсь, это должно помочь прояснить ситуацию. Однако, если я что-то пропустил, дайте мне знать, и я постараюсь ответить.

Источник

PHP. Изменить Return-path

Из-за обилия спама человечеству приходится ухищряться и придумывать разнообразные фильтры писем. Эти фильтры действуют по нескольким критериям. Одним из которых является адекватное значение Return-path. По моим наблюдениям, если значение выставлено неверно, то шанс попадания письма в папку «спам» увеличивается почти на 30%.

Обычно для Return-Path ставят аналогичное значение, что и для поля «From». В противном случае вероятность попадания в папку «спам» увеличивается почти на 30%.

В чём проблема

Рассмотрим на примере: есть сервер с php и SendMail. Отправляется письмо через стандартную функцию mail():

И к получателю письмо приходит со следующими заголовками:

From: «AlexGur»
Return-path: user@ server_name.server_domain
Reply: «AlexGur»

С большой вероятностью это письмо попадёт в папку «спам», если значение Return-path не содержит домен со следующими свойствами:

Но даже если сделать эти записи, то некоторые почтовики всё равно могут выдавать предупреждение о невозможности подтвердить отправителя.

Проблема в том, что Return-path генерируется автоматически, но его можно задать вручную, через пятый параметр функции mail():

Почему через PHP, а не файл конфига

php_admin_value sendmail_from » me@alexgur.ru «

Или в случае моей конфигурации сервера:

Потратил четыре часа, чтобы понять, почему Return-Path не может принять правильно значение. Перерыл весь мануал SendMail.

Источник

Грамотная настройка сервера отправки почты для скриптов PHP, настройка функции mail()

В этом топике вы узнаете, как грамотно настроить, сервер исходящей почты и в частности функцию mail() в PHP. Сам являюсь жутким педантом. Люблю, что бы везде было все на своих местах, не терплю халтуры. Увидев один раз полную чушь в заголовках письма со своего сервера я разобрался с этим кардинально и безоговорочно. Под грамотной настройкой я подразумеваю такую, которая удовлетворяет потребности спам фильтров крупных почтовых систем, и просто выглядело красиво и осмысленно.

Как известно протокол SMTP не подразумевает никаких средств защиты от спама и аутентификации пользователя, поэтому крупными и не очень компаниями были придуманы «фиксы» безопасности протокола.
Если вы устанавливаете выделенный сервер с доменом размещенным на нем, очень рекомендуется выполнить данные настройки, что бы все было как надо.

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

Название заголовка выбрал именно такое, так как вначале своего пути я искал что-то вроде этого. Настраивать будем postfix, php, dns (ptr, spf), и другое.

Эта статья будет интересная людям, настраивающим выделеные сервера, но не менее интересна для обычных программистов.
К слову данную инструкцию я использую для своих проектов. Системы автоматизированного получения приглашений и получения виз в страны Шенгена: https://goingrus.com/ru, весь софт крутится на виртуальной машине.

Подробности под катом

Преамбула

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

Статья отформатирована не самым лучшим образом. Извиняюсь, время поджимает, а рассказать хочется пока вспомнил, а то потом не времени будет.

Чем проверять нашу работу?

Тестируем вот этим методом

Мы будем очень много читать заголовки писем. Просматривать заголовки очень удобно в gmail, там есть такая фишка в 2 клика, сами найдете.

Каких целей в заголовках нам требуется достичь?

— Вот этих заголовков от gmail.com
Прошу заметить, что это заголовки с которыми письмо попадает в ящик конечного пользователя

— А так же этих заголовков от mail.ru

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

Приступим

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

— Настройка PHP
Ставим как хотим php, это вы как-нибудь без меня.

Идем в настройки php, заменяем эквивалентно:

Этим мы указали заголовок Return-Path:

Кстати 1: это будет таковым для всех виртуальных доменов сервера, что бы это исправить и настроить под текущий, то требуется передать 5-й параметр в функцию mail().

Кстати 2: если вы поставите 5-й параметр на обычном виртуальном хостинге, то вам тоже рекомендуется проводить настройку вашего домена, как это описано ниже. Обращаю внимание, что операцию с PTR записями сделать невозможно, так как 1 IP = Домен, ну или по крайней мере не рекомендуется делать их 2, не помню уже.

— Настройка MTA, он же локальный сервер исходящей почты
Я вам искренне советую postfix, далее идем в настройки /etc/postfix/main.cf
для тех, кто уже нарвался на sendmail, и понял как они трудно выпиливаются из системы, советую команду:

Далее, делаем эквивалетно вот так
myhostname = goingrus.com
#smtp_helo_name = srv.goingrus.com
mydestination = _ALL_, goingrus.com, srv.goingrus.com, localhost.goingrus.com, localhost

(srv.goingrus.com — это мой сервер в домене goingrus.com)

— Если я не ошибаюсь, это помогло. Когда агент доставки представляется другому серверу передается HELO. Поменяете myhostname, поменяется следующий заголовок:
Message-Id:

— smtp_helo_name по дефолту это myhostname, читаем матчасть

— mydestination — если я не ошибаюсь, это задает те домены с которых MTA будет принимать почту на обработку, если у вас виртуальный хостинг (что я устроил на сервере дома), то без _ALL_ у вас будут проблемы с отправкой почты с других доменов кроме указанных.

Ну вот, видите, заголовки уже намного правильнее не так ли, а то ужас поначалу был.

— Разборки с почтовыми сервисами (почтовики)
А они нас считают как недобрый источник.
Наш сервер смог правильно helo представиться, но вот только почтовики нам все равно не доверяют.
Для этого были придуман алгоритм, для того что бы владелец домена с помощью DNS (если он конечно грамотный как мы) мог указывать, что вот таким-то серверам можно доверять, а другим нельзя.

У вас вместо ужаса который сейчас должно получиться вот это:

Мы уже на пути к истине. К слову, по умолчанию, почтовик все считает как v=spf1

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

v=spf1
это означает, что версия алгоритма spf1

+mx
Можно доверять почте если она отправлена с серверов mx, например если mx.goingrus.com это сервер приема, то если этот сервер будет отправлять, то все будет хорошо.

+a:goingrus.com
Можно доверять серверу, обслуживающий домен goingrus.com

так же добавлю, например на моем почтовом сервере разместился pupkin.ru.
Я дал Пупкину погонять мой почтовый сервер исходящей почты srv.goingrus.com (обычная ситуация виртуального хостинга, он всегда стоит локально, как бд, и все все все). Тогда он у себя должен настроить +a:srv.goingrus.com

+include:gmail.com
Импортируем все правила gmail.com, у них тоже есть такая запись TXT для своих серверов. (я использую сервисы google для домена)

-all
Указываем, что админ считает другие места не своими, и это может быть ближайший бордель в подворотне рассылающий спам от моего имени
(+all а это означает, что весь мир мои друзья)

— Разборки с почтовыми сервисами, настройка обратной PTR
Почтовики еще спрашивают обратные доменные зоны PTR для дополнительной галочки, думаю эта галочка одна из самых жирных, так как она 100% определяет сервер, и если он ведет себя правильно, то ему очень сильно доверяют и любое письмо наверняка дойдет до адресата.
X-Mru-PTR: goingrus.com, он же есть в google наврное это Received: from goingrus.com (goingrus.com. [188.134.79.140])

Заметка:
В виртуальном хостинге вам это сделать не дадут, у них на этот адрес замапин свой сервер, какой-нибудь servername.badhosting.ru, на котором вы и размещаетесь, да и вообще только на собственном серваке с собственным IP это возможно провернуть.

Интересно: Если вы живете дома, а у меня один из серверов стоит дома, в частности goingrus.com. Что делать? вроде IP выделенный, а обратный адрес, не настроить. Я позвонил выше (к провайдеру) сказал мол так и так хочу PTR зону. Мне её сделали, очень доволен.

Еще немного слов о заголовках (все вперемешку)

X-Mru-BL: 0:0:0:0 упаси вас иметь что-нибудь кроме нолей, это блеклисты.
X-Mru-OF: интерфейс с которого посылается, я так и не понял от чего это зависит.
X-PHP-Originating-Script: — я бы советовал добавлять, хотя если вы очень печетесь о безопасности и неразглашении, то можно и запретить. Делается это неподалеку от той настройки PHP которой мы делали. По умолчанию включено.

Еще можно и интересно посмотреть что пишет Яндекс при приеме, очень интересно.

Дополнительно

Там еще какие-то цифровые подписи есть.
определяется заголовком, DKIM-Signature
С виду у меня уже было все в порядке, а этот заголовок не очень нужен. Он нужен обычно сервисом очень крупного масштаба вроде facebook или google где рассылка уведомлений и почты идет в гигатонном масштабе. Если ваш сервис не обладает миллионами пользователей, то не думайте об этом, хотя если вы изыскатель — напишите как об этом здесь и мы свяжем статьи — что бы все казалось полностью законченным, только я прошу намного проще написать, так как уже где-то видел статьи про это все. От себя добавлю что мне было лень устанавливать еще один пакет, разбираться и еще что-нить.

Материала к сожалению нет, так как по крупицам отовсюду собирал 4 месяца назад, потом меня не было времени, а теперь я написал по памяти.

Удачной грамотной настройки вашего сервера. Я попробовал объяснить хотя бы один из нескольких аспектов настройки.

Источник

В чем разница в поведении между return-path, reply-to и from?

В нашем почтовом приложении мы отправляем электронные письма со следующим заголовком:

Проблема, с которой мы сталкиваемся, заключается в том, что некоторые серверы email немедленно отскакивают назад сообщение и вместо этого используют путь от или обратный путь ([email protected]) к нашему серверу bounce mgmt. Мы хотим знать, изменим ли мы в заголовке ответный путь, чтобы он был таким же, как обратный путь, если мы сможем поймать все отскоки.

Любые другие идеи приветствуются?

EDIT 1: еще несколько битов информации, чтобы увидеть, сможем ли мы получить это решение.

Мы хотим знать, в какой момент сервер email, ретранслирующий сообщение, предпочтет использовать ответный путь по сравнению с обратным путем. Мы заметили, что когда первый сервер smtp, ретранслирующий сообщение, получает отклонение, он отправляет его в reply-to, но когда это происходит после одного прыжка, он отправляет его в return-path.

4 ответа

Где и представляют соответственно команды клиента и сервера.

Почта получателя будет выглядеть так:

Теперь давайте опишем различные «FROM».

Все отскоки, которые происходят во время сеанса SMTP, должны возвращаться по адресу обратного пути. Некоторые серверы могут принимать все email, а затем помещать их в очередь локально, пока у них не будет свободного потока для доставки их в почтовый ящик получателя. Если получатель не существует, он должен вернуть его обратно к записанному значению обратного пути.

Обратите внимание, что не все почтовые серверы подчиняются этому правилу; некоторые почтовые серверы будут возвращать его обратно на адрес FROM.

Заголовок ответа добавляется отправителем (или программным обеспечением отправителя). Именно здесь должны быть адресованы и все человеческие ответы. В принципе, когда пользователь нажимает «reply», значение ответа должно быть значением, используемым в качестве получателя вновь составленного email. Значение Reply-To не должно использоваться никаким сервером. Он предназначен только для использования на стороне клиента (MUA).

Однако, как вы можете заметить, не все почтовые серверы подчиняются стандартам или рекомендациям RFC.

Надеюсь, это поможет прояснить ситуацию. Однако, если я что-то пропустил, дайте мне знать, и я постараюсь ответить.

для тех, кто попал сюда из-за названия вопроса:

Я пытаюсь понять, в чем разница между ними. путь = путь + [node1] путь += [node1] path.append(node1) Я получаю правильный путь для path = path + [node1], но не для двух других. def find_path(self, node1, node2, path = []): Finds any path from node1 to node2 which may not be the shortest path =.

Похожие вопросы:

В чем разница между значением email Sender, From и Return-Path? Пример : у меня есть контактная форма, где пользователь может ввести свой email, будет ли это назначено отправителю, from или.

Пример: nginx.conf location ^

Я пытаюсь понять, в чем разница между ними. путь = путь + [node1] путь += [node1] path.append(node1) Я получаю правильный путь для path = path + [node1], но не для двух других. def find_path(self.

Я использую Microsoft Graph reply and forward APIs. Я пытаюсь понять их разницу. Сначала я подумал, что conversationId может измениться, если я использую forward. Оказывается, conversationId не.

Источник

В чем разница между Sender, From и Return-Path?

в чем разница между отправителем электронной почты, значением From и Return-Path?

пример: у меня есть контактная форма, где пользователь может ввести свою электронную почту, будет ли это назначено отправителю, от или обратный путь?

У меня был быстрый поиск на StackOverflow и не смог найти ничего полезного.

3 ответов:

Итак, по SMTP при отправке сообщения, конверт SMTP (отправитель, получатели и т. д.) отличается от фактических данных сообщения.

The Sender заголовок используется для идентификации в сообщении, кто его отправил. Обычно это то же самое, что и From заголовок, от которого исходит сообщение. Однако он может отличаться в некоторых случаях, когда почтовый агент отправляет сообщения от имени кого-то другого.

The Return-Path заголовок используется для указания на получатель (или получающий MTA), куда должны быть отправлены квитанции о недоставке.

в этом случае, если сообщение не может быть отправлено, агенту, вероятно, лучше получить отчет о недоставке, и поэтому Return-Path также будет иметь значение mailagent@mywebmail.com так что любые отчеты о доставке идут к нему вместо отправителя.

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

официальный RFC, который определяет эту спецификацию можно найти здесь:

2.1.2. Поле Заголовка: From

2.1.3. Поле Заголовка: Отправитель

2.1.22. Поле Заголовка: Return-Path

Источник