Как написать почтовую программу

Для новых проектов Microsoft НЕ рекомендует использовать данный API и взаимен рекомендует использовать сторонние библиотеки, например, MailKit.

Для отправки почты в среде интернет используется протокол SMTP (Simple Mail Transfer Protocol). Данный протокол указывает, как почтовые сервера взаимодействуют при передаче электронной почты.

Для работы с протоколом SMTP и отправки электронной почты в .NET предназначен класс SmtpClient из пространства имен System.Net.Mail .

Этот класс определяет ряд свойств, которые позволяют настроить отправку:

• Host : smtp-сервер, с которого производится отправление почты. Например, smtp.yandex.ru
• Port : порт, используемый smp-сервером. Если не указан, то по умолчанию используется 25 порт.
• Credentials : аутентификационные данные отправителя
• EnableSsl : указывает, будет ли использоваться протокол SSL при отправке

Еще одним ключевым классом, который используется при отправке, является MailMessage . Данный класс представляет собой отправляемое сообщение. Среди его свойств можно выделить следующие:

ПРОГРАММА ДЛЯ АВТОМАТИЧЕСКОЙ РЕГИСТРАЦИИ АККАУНТОВ НА ПОЧТОВЫХ СЕРВИСАХ

• Attachments : содержит все прикрепления к письму
• Body : непосредственно текст письма
• From : адрес отправителя. Представляет объект MailAddress
• To : адрес получателя. Также представляет объект MailAddress
• Subject : определяет тему письма
• IsBodyHtml : указывает, представляет ли письмо содержимое с кодом html

Используем эти классы и выполним отправку письма:

Для отправки применяется метод Send() , в который передается объект MailMessage.

Также мы можем использовать асинхронную версию отправки с помощью метода SendMailAsync :

Добавление вложений

К письму мы можем прикрепить вложения с помощью свойства Attachments. Каждое вложение представляет объект System.Net.Mail.Attachment :

Источник: metanit.com

Проектируем удобный почтовый клиент

Недавно, просматривая старые статьи Хабра, наткнулся на опрос о почтовых клиентах, который показал, что подавляющее большинство читателей предпочитает Gmail. Я сам пользуюсь им много лет, хотя пару раз в год безрезультатно пытаюсь “пересесть” на что-то поудобнее. С тех пор я стал думать о том, как можно было бы сделать Gmail лучше.

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

Низкий старт. Портрет пользователя и позиционирование

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

Лучшая электронная почта

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

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

Начало

Конкурентов нужно знать в лицо. Я протестировал десяток веб-клиентов из опроса и сделал выводы, которые учел при дальнейшем проектировании. Когда я создавал прототип, прежде всего руководствовался не принципом “чтобы было не похоже на. ”, а своими логическими соображениями, законами Фиттса и Хика, работами Раскина, Купера и других авторитетных проектировщиков.

Сразу запустил небольшой опрос по друзьям в соц.сети:

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

Самое главное: интерактивный прототип

Некоторые бросаются сразу делать дизайн. Честно говоря, я совершенно не понимаю, как можно отлаживать “механику” взаимодействия на графических макетах. В общем, начинаем с интерактивного html-прототипа в Axure, в котором можно было бы прямо по ходу проектирования тестировать и переделывать различные элементы взаимодействия.

Далее приведу наиболее интересные скриншоты с пояснениями. Если любопытно пощупать руками, в конце статьи вы найдете ссылку на прототип.

Итак, авторизуемся под аккаунтом Gmail, разрешаем приложению использовать данные, попадаем во входящие

Своему почтовому клиенту я дал временное рабочее название UXMail и буду использовать его только в рамках этой статьи.

На всякий случай уточню, что это лишь функциональный прототип, а значит все цвета, шрифты, иконки и формы — лишь условные, внимания на стиль обращать не стоит: все будет нормально “отрисовано” позже профессиональным дизайнером.

Навигация и письма

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

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

И тут не обошлось без GTD и геймификации

Я уважаю принципы методологии Getting Things Done о “пустом инбоксе”, поэтому в интерфейсе старался всячески мотивировать не откладывать обработку писем, и как можно скорее очистить папку с входящими. Например, когда последнее письмо отправляется в архив, UXMail хвалит пользователя

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

При наведении на письмо во входящих появляется кнопка добавления этого письма в архив. Пользователю достаточно будет подвинуть курсор на несколько пикселей и кликнуть по иконке:

После чего письмо с анимацией “улетает” в иконку архива в меню.

Закон Фиттса как всегда безупречен

Для сравнения, то же самое действие — добавление в архив — в Gmail. Пользователь вынужден каждый раз проделывать пять(!) операций вместо двух:

1. Подвести курсор к флагу
2. Установить флаг
3. Подвести курсор к кнопке “в архив”
4. Кликнуть
5. Перевести курсор на следующее письмо

Отвечаем на письмо

В интерфейсе входящего письма ничего концептуально нового нет. При клике поле ввода “разъезжается” до состояния, в котором удобно написать ответ

Менее популярные элементы интерфейса скрыты. Например, копия при ответе. Панель форматирования сильно приглушена цветом, но при наведении и клике инструменты “подсвечиваются”:

Отмена и подтверждение действий

К модальным подтверждениям типа “Вы уверены, что хотите . ” пользователи быстро привыкают и машинально нажимают “да” даже не вчитываясь. Поэтому лучше делать всплывающие уведомления: в таком случае у пользователя будет 3-4 секунды, чтобы передумать и отменить свое решение

Цепочки писем и микроцепочки

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

1. Не понятно, сколько новых писем появилось в цепочке. Просто появился один “непрочитанный” элемент — цепочка по теме
2. Открывая цепочку, все письма помечаются как “прочитанные”. В результате можно пропустить новое письмо
3. Непонятно, к какому письму цепочки будут применены общие действия (ответить, переслать и другие). Хотя в Gmail это уже частично решено, чего не скажешь о некоторых других клиентах

У цепочек есть и одно существенное преимущество: они позволяют проследить всю линию общения и вспомнить какую-то важную информацию. Признаться, я сначала тоже собирался делать цепочки, “приглушив” перечисленные недостатки рядом интерфейсных “костылей”, но при этом UXMail терял в простоте и минималистичности.

В итоге я решил ввести новое понятие — микроцепочки. Фактически, микроцепочка — это входящее сообщение и ответ пользователя на это сообщение. Такой механизм позволяет сохранить простоту и прямолинейность интерфейса без цепочек и получить определенные преимущества интерфейса с цепочками хотя бы в рамках одной итерации “входящее письмо — ответ на него”. В подавляющем большинстве случаев этого достаточно, чтобы восстановить в голове смысл переписки

Проверяйте спам чаще

Папку со спамом я сознательно “вытащил” на верхний уровень. Я считаю, что пользователям стоит хотя бы изредка проверять спам на предмет важных писем, потому что спам-фильтры пока не 100% корректно работают. Соответственно, предполагается такое взаимодействие: пользователь пробегает глазами список писем в спаме, с помощью быстрой кнопки отправляет некоторые письма обратно во входящие, а в конце списка его ждет большая кнопка “Удалить весь спам безвозвратно” — и далее будет опять хвалебная надпись и картинка

Метки и фильтры: их-то за что?

А вот фанатам меток и фильтров UXMail скорее всего не понравится: фильтры придется настраивать через интерфейс Gmail, а меток вообще нет — остались только папки

1. Нарушается принцип “одного пустого инбокса”. Т.е. чтобы продуктивно обрабатывать почту нужно следить за тем, чтобы сразу несколько папок были пустыми или хотя бы просто обработанными
2. Увеличивается вероятность пропустить важное письмо: человек — не робот: может банально забыть о какой-то папке и не проверить ее
3. Если посадить два человека рядом и слать им одни и те же письма, то, рискну предположить, обрабатывать поток писем быстрее будет тот, кто получает все в одну папку, т.к. он не тратит время на переключение между папками

По поводу меток я в сомнении: пока решил их вообще не поддерживать. Метки — это когда все письма остаются в общем “инбоксе”, просто помечаются словами “работа”, “учеба” и так далее. Я как-то пользовался метками, потом перестал, т.к. обратил внимание, что они улучшают продуктивность лишь ненадолго. Потом приходится систематически тратить время на “ревью” созданных меток и добавление новых. Это при том что в 9 из 10 случаев и так понятно, какое письмо по учебе, а какое — по работе.

Управление вложениями

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

Все-все, уже закругляемся. Настройки

Я изучил интерфейсы настроек нескольких популярных почтовых клиентов, подумал и убрал все лишнее. Осталось только 4 раздела: почтовые ящики, подписи, автоответчик и уведомления

Каждая настройка в обязательном порядке сопровождается пояснительным текстом и иллюстрацией того как это будет выглядеть в интерфейсе. Некоторые настройки продублированы в “повседневных” интерфейсах. Например, можно добавить еще один адрес отправителя прямо из контекста создания нового письма:

А когда пользователь включает автоответчик, в верхней панели статично закрепляется сообщение о том, что включен автоответчик

Это должно хоть немного мотивировать пользователей включать автоответчик только по “уважительным причинам” вроде отпуска или болезни. Надеюсь, станет чуть меньше получателей, от которых в ответ на каждое письмо автоматически приходят страшные слова в духе “Спасибо, я получил вашего сообщение”.

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

Какие планы?

Собрать отзывы с Хабра, доработать прототип, сделать графический дизайн и промо-материалы, привлечь инвестиции на разработку через краудфандинговые платформы.

И зачем я это все написал?

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

Источник: habr.com

Как написать почтовый клиент на чистом PHP

Мне нужно написать почтовый клиент на PHP. В нем должны присутствовать две вкладки, «Входящие» и «Отправленные». Как реализовать функционал «Отправленные» я понимаю, через функцию mail() . Правильно я понял, что нужно будет сохранять копии писем в БД, а потом их выводить? Но как реализовать функционал «Входящие»? Мне не совсем понятно.

Нужна ваша помощь.

Отслеживать
51k 83 83 золотых знака 262 262 серебряных знака 500 500 бронзовых знаков
задан 28 авг 2017 в 14:19
Александр Салычев Александр Салычев
41 4 4 бронзовых знака
На затравку php-zametki.ru/php-nachinayushhim/…

28 авг 2017 в 14:27

pop3 который вам предлагают выше для таких целей плохо пригоден ибо заставит сохранять копии всех писем в БД и выводить статус от туда же. Лучше использовать протокол IMAP, если его поддерживает почтовый сервер. Он позволяет хранить все прямо на почтовом сервере, искать по разным критериям и т.п. и вы в php скрипте можете спокойно вообще нигде у себя ничего не хранить получая всегда прямо с imap-сервера

28 авг 2017 в 14:34
28 авг 2017 в 14:40
28 авг 2017 в 14:45
28 авг 2017 в 14:47

1 ответ 1

Сортировка: Сброс на вариант по умолчанию

Почтовый сервер свой, или сторониий от яндекса/гугла? Учитывая, что на PHP, клиент будет так же на сервере, который постоянно в сети?

Не храните почту в базе, пусть лежит на сервере.

Не отправляйте почту функцией mail(), вам предварительно придется сформировать письмо согласно всем RFC, это совсем не просто, так что хватит писать велосипеды, используйте библиотеки PHPmailer или SwiftMailer. Второй по описаниям мне приглянулся больше, но у него странный валидатор, не пропускает исходящие на почту в четырехбуквенной доменной зоне (.info .club .name и тп), или просто я не смог его заставить сделать это.

Используйте функции IMAP для работы с письмами в папках (просмотр-удаление и тд)

Источник: ru.stackoverflow.com