Який найкращий спосіб надсилання електронної пошти від імені моїх клієнтів?


15

Мені хотілося знати найкращий спосіб змусити мій сервер пошти надсилати електронні листи від домену моїх клієнтів, не маючи в сірому списку, а також уникаючи проблем з відмов.

Я читав деякі інші питання тут , тут і тут, але жоден не вивчає всіх можливих рішень. Ось кілька можливостей, які я хотів би порівняти:

A.

HELO mymailserver.com
MAIL FROM<do-not-reply@myapp.com>  # mymailserver.com same IP as myapp.com
DATA
  From: <res@client.com>
  Sender: <do-not-reply@myapp.com>

Питання : Це те, що робить gmail. Це заголовок msg "From:", який має інший домен, а не відправник конверту.
emailclients покаже "Від: res@client.com через do-not-reply@myapp.com" або "Від: do-not-reply@myapp.com На поведінці res@client.com" , що не є проблемою для мене.
Тепер, чи це погано вплине на репутацію мого домену, на те, що заголовок "Від:" має інший домен? (і якщо це не Google, хто це робить ...)

Б.

HELO mymailserver.com
MAIL FROM<do-not-reply@myapp.com>
DATA
   From: <res@client.com>
   # same as A, but no "Sender:"

Схоже, колись Google це зробив і назвав це помилкою http://groups.google.com/group/Gmail-Help-Message-Delivery-en/browse_thread/thread/f651cb1db5d9dd23/3a8bcd0548487863?lnk=gst&q=%22on+behalf + of% 22 & pli = 1
Помилка видалила "Відправник:" з їхніх повідомлень, а "via" не з’явилося в emailclient. (RFC каже, що ОБОВ'ЯЗКОВО бути присутнім, якщо він не є таким, як "From:")

C.

HELO mymailserver.com
MAIL FROM<res@client.com>
DATA 
  From: <res@client.com>

Це так, ніби client.com надсилав повідомлення (ПОЧТА ВІД "теж" підроблена). Але якщо домен client.com добре відомий або в його DNS є запис SPF, мені доведеться змінити його DNS, дозволяючи mymailserver.com надсилати повідомлення від їх імені .. (Для мене це неможливо через nb . клієнтів, а також деякі мої клієнти не мають контролю над своїми доменами, тобто самі використовують @ gmail.com)

D.

HELO mymailserver.com    
MAIL FROM<do-not-reply@myapp.com>
DATA 
  From: <do-not-reply@myapp.com>
  Reply-to: <res@myclient.com>

Питання : Це найпростіший, я додав би лише заголовок "Відповідь до:". Це дійсно враховано ВСІ ЧАСИ електронними клієнтами? Чи можна це сприймати і як підробку, додаючи різні домени до заголовка "Відповісти до" і бути поганим впливом на репутацію мого домену?
- RFC говорить лише про те, що "якщо поле" Відповідь до "існує, відповідь ДОЛЖЕН би перейти на адреси, зазначені в цьому полі, а не на адреси (адреси), зазначені в полі". "
- Лише заголовок "Від:" буде "підроблений":
"Від: myclient.com (через myapp.com) <do-not-reply@myapp.com>".


Читаючи RFC, "ПОТРІБНО" означає, що це дуже сильна рекомендація. Єдина причина, яку клієнт не робив би в більшості випадків - це те, що він старий і не оновлювався з моменту написання цього RFC. Стандартні визначення див. У RFC 2119: ietf.org/rfc/rfc2119.txt
Меттью Шарлі


На жаль, станом на 2018 рік багато клієнтів електронної пошти все ще ігнорують заголовок відповіді. meta.discourse.org/t/…
Мартін Мейксгер

Відповіді:


2

Відмінне запитання. Я щойно провів кілька годин на дослідженні того ж самого.

Раніше я розгортав численні веб-сайти, які використовують опцію C для форм електронної пошти (в основному не наївно), але ми відчуваємо все більше проблем із доставкою. Постачальники електронної пошти поступово затягують справи. Наприклад, Yahoo нещодавно змінив політику DMARC, щоб просити одержувачів відхиляти всі електронні листи From: ____@yahoo.comбез дійсного підпису DKIM . Отримання SMTP-серверів, які слідкують за DMARC (що включає Gmail, і, ймовірно, Hotmail / Outlook.com та Yahoo), важко відкине ці повідомлення. На мою думку, eBay та Paypal мають схожу сувору політику щодо спроби зменшити фішинг. На жаль, зазначення заголовка "Відправник" не допомагає.

(Цікаво, як Gmail працює над цим, надсилаючи псевдонім Yahoo "From" ?!)

Варіант A був би кращим варіантом, якщо ви знаєте, що в електронній пошті "Від" немає чіткої політики DMARC (ви можете це підтвердити за допомогою простого запиту DNS).

Незважаючи на те, що є найменш візуально привабливим, варіант D справді найбезпечніший і саме це я рекомендую для більшості наших майбутніх проектів. Варто відзначити , що PayPal раніше використовували варіант А, але тепер переключився на Option D .

Щоб отримати додатковий авторитет та збільшити шанси на поставку, я би розглядав можливість впровадження SPF та / або DKIM. Ці та інші речі згадуються в Посібниках Google щодо масових відправлень, які я вважаю корисними.


1

Я не впевнений, чого ти хочеш. Не існує "безпечного" чи "небезпечного" способу робити те, що ви хочете.

Я б завжди віддав перевагу D). Додатково я додав би записи SPF. Але, як я вже говорив, це не безпечніше чи небезпечніше інших (що б ви не мали на увазі під цим).

Заголовок відповіді-до жодним чином не впливає на репутацію. Він лише радить клієнту використовувати цю адресу для відповідей (Дюх, можливо, саме звідси походить назва ?!). Якщо клієнт дотримується цієї рекомендації, це не гарантується.


Під "безпечним" я маю на увазі мінімізацію шансів на те, щоб мій домен був переглянуто в грейлістському списку, помилково розглядався як підробник / спамер через вибране нами рішення. Так, якщо я перейду з D, я можу розглянути можливість додавання запису SPF до свого домену та підписання повідомлень за допомогою DKIM.
dgaspar

Я відредагував своє запитання і спробував його уточнити ..
dgaspar

@dgaspar Greylisting - це конверт. Тож ваш вміст (Від:, Відправник:, ...) повністю ігнорується. Оскільки кожен може написати будь-яку адресу електронної пошти як відправника, кожна адреса відправника вважається підробленою. За винятком того, що ви підписуєте свої листи за допомогою SPF або DKIM.
mailq

0

Два надійних рішення:

  1. попросіть клієнтів додати ваш поштовий сервер у свій запис домену SPF
  2. попросіть клієнтів надати вам облікові дані електронної пошти (їх IP-сервер поштового сервера, ім’я користувача, пароль) та використовувати їх у вашій програмі для підключення до свого поштового сервера та надсилання електронної пошти (ви фактично створюєте клієнт електронної пошти всередині своєї програми).
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.