Saboteur

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

Либо даже размножить через mailalias в скрипт и на почту, а в скрипте уже отбирать нужные письма и автоматом извлекать то, что нужно
Например, вы юзаете postfix, и у вас в конфиге постфикса настроен дефолтный путь для алиасов (alias_maps=hash:/etc/aliases)

Тогда в /etc/aliases нужно прописать
username: "|/path/to_script"

можно сделать копирование
username: username, "|/path/to_script"

Чтобы вступило в силу, выполнить newaliases после правки /etc/aliases

если не постфикс, посмотреть доку по вашему почтовому серверу

В пределах компании на корпоративном exchange можно было бы через outlook forms сделать такое. Там вообще много чего в плане документооборота можно сделать.

В рандомном интернете можно разве что написать текст опросника и попросить заполнить согласно какому-нибудь формату, например

1. вопрос
ответ

2. вопрос
ответ

И потом ловить такие ответы и парсить уже на вашей стороне. Но валидация ответов на стороне клиента не получится.

Конечно можно.

Но такое письмо зарубит ближайший спампротектор.

Поэтому работать будет в пределах вашего почтового сервера (например рассылать служебные рассылки от несуществуюшего пользователя), но наружу такие письма с вероятностью 99% будут резаться на всех почтовых узлах.

Какой почтовый сервис для домена выбрать, чтобы фото профиля отображалось у всех получателей?

Тебе же уже отвечали - не существует такого сервиса.
Аватарки не поддерживаются почтовым протоколом, это работает исключительно внутри сервисов.
Зарегался на яндекс - пользователи с яндекса могут видеть аватарку, если они пользуются веб яндексом.

Для гугла максимум можешь зарегать там почтовый ящик и добавить свой емайл в гугл. Тогда можно уже на гугловский профайл повесить аватарку и слать с основного емайла - пользователи гугловской веб почты увидят аватарку связанного профайла.

Но.
Нет такого стандарта. Все кто пользуются аутлуком, батом и другими - не увидят. Забей.

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

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

А иначе - никак.

релеи и клиенты-сервера,

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

Зачем нужно это все?

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

В одном почтовом ящике есть только одни экземпляр письма, у него только один флаг прочитан/не прочитан.
Или делаете список рассылки и всем рассылаете индивидуальные копии, или создаете в почтовом ящике папку, и прочитанное письмо прочитавший руками переносит в другую папку. Можно для каждого свою сделать.

Именно так, чтобы просто перетаскиванием письма в папку создавалось правило сортировки - такого нет.
А кнопочка "создать правило сортировки" есть практически в любом клиенте.

Собственный домен и сколько угодно емайлов. А если еще и свой почтовый сервер, то вообще как бог.

Поля "От", "кому", "Subject" - не являются системными полями, их просто отрисовывает почтовый клиент. А в заголовке в RCPT TO и MAIL FROM можно указать что угодно. Лишь бы почтовый релай позволит отправить, а ваш почтовый сервер не режектнул.

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

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

Да любой хостинг, вообще любой. 90% провайдеров инета предлагают парралельно свой хостинг - можете купить у них минимальный, для почты, и всегда можно будет позвонить по телефону.
А так - привязать свой домен можно и к gmail и к yandex и свой почтовый сервер поставить на любом vs

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

В Unix/Linux еще в прошлом веке можно было замапить емайл на какой-то скрипт одной строкой в конфиге.
То есть почтовый сервер при получении письма, сразу запускает скрипт и скармливает ему текст сообщения.

Сейчас тоже самое - берется письмо и скармливается программе, которая его парсит и выполняет нужные действия.
Просто ищите как это настраивается на вашем почтовом сервере.

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

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

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

Может быть что угодно.
Например SMTP изначально был рассчитан на работу с емайлами, набранными исколючительно латинскими, и неизвестно на чем крутится ваш обработчик, может на чем-то древнем, что еще не умеет punycode (для этого не обязательно быть древним, всего лишь старше чем 3-4 года).

UTF8SMTP в RFC появился вроде только в 2008, И до сих пор имеет статус experimental.

Поэтому либо логи в студию, либо разберитесь с конвертацией отправляемого емайла в punycode