Проблемы разработки почтового сервера - PullRequest
0 голосов
/ 25 августа 2010

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

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

Мне сообщили, что регистрация в следующих организациях поможет.Но мой вопрос в том, что одного этого будет достаточно?

Рабочая группа по борьбе с злоупотреблениями сообщениями (www.maawg.org)

Совет по работе с электронной почтой (www.emailexperience.org)

Online Trust Alliance (www.otalliance.org)

Коалиция поставщиков услуг электронной почты (www.espcoalition.org)

Путь возврата (www.returnpath.net)

СпамАрест (www.spamarrest.com)

Что еще нужно сделать во время разработки или настройки службы?

1 Ответ

0 голосов
/ 02 сентября 2010

Учитывая, что SMTP не имеет понятия "учетные записи", только отправители и получатели, ваш вопрос не имеет большого смысла. Если принимающий сервер решит, что ваш компьютер генерирует спам, то он, вероятно, внесет в черный список ваш IP, а не любую «учетную запись», использованную для запуска почтовой программы (хотя он может решить занести в черный список адрес отправителя).

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

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

...