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

И да. Всем мир! ;)

Простите, если был неправильно понят. Это скорее ответ в весь тред, к тому же комментарии читаем не только мы с вами.
Вы абсолютно правы — вставлять нужно только email. После подтверждения — уже можно вставлять UGC.

Ваша идея понятна и абсолютно здрава. Но реальность пока такова, что 99,9 интернета пока работают по «классическим» формам подписки, обратной связи и тп (напомню, что уязвима не только форма подписки, вектор — инъекция UGC в письма, и этот вектор может проявляться и в других кейсах).
Очень близкое по духу вашей идеи решение сервису имплементировать возможность пользователю авторизацию почтового провайдера.
Я уверен, что в ближайшие лет 5 механизмы подписки/отписки шагнут вперед. Но здесь довольно много препятствий в виде стандартов. RFC очень инертная штука.

Подписка подразумевает подтверждение email (DOI процедура).
Письмо подтверждения может содержать, а может и не содержать данные, введенные пользователем в других полях, либо подтянутые из базы (случай личного кабинета или CRM). И вот тут то и кроется соль.
Письмо вида
To: %username% <%useremail%>
Subject: %username%, подтвердите Ваш email
Здравствуйте, %username%!
Спасибо за регистрацию на ресурсе example.com!
дойдет.
Но, например, в переменной %username% может содержаться как имя: «Вася, Петя, Мария, Белый господин», так и спам-контент.
Мой посыл пока email получателя не подтвержден — не вставлять в письмо UGC.

В случае обратного звонка контент пройдет «модерацию» мозгом оператора кол-центра. Вряд ли он будет обращаться «Мой белый господин!» или среагирует на спам. :) Так что тут соглашусь.

Можно очень сильно закрутить гайки. Можно, например, не давать вбивать имя, а только выбирать из списка, ну и тд. Но тут вопрос к балансу между защитой и конверсией. Слишком строгие правила — отпугнут часть посетителей. Слишком мягкие — пропустят спам.
По моему убеждению имя и прочие данные пользователя на стадии первого знакомства — пока email еще не подтвержден — вообще не нужны, и не надо его мучать вводом лишних данных. Потом, когда он пройдет по воронке, когда его лояльность к сервису вырастет — тогда и анкетировать. Но опять же — не для того чтобы вставить имя в текст письма, а чтобы сегментировать базу, делать действительно персонализированные письма… Но об этом Дима Кудренко очень хорошо написал. Ссылка есть в статье.

Не скажу за фронтендеров :) Но мне кажется, что исключение семантических тегов может не очень хорошо отразится в каких-то кейсах (например использовании аналитических систем), да и лишний JS там где можно обойтись HTML — тоже в общем случае не очень хорошо. Но не хочу развивать холивар на эту тему ))).
Замечательно, что у вас есть методы, которые работают. Моя задача — показать чуть более широкий набор мер и предложить оптимальный по простоте и эффективности.

Спасибо всем за комментарии в этой ветке! Я обязательно передам идеи продуктовой команде.

Спасибо за внимание к статье! К сожалению, это не дает гарантий. В своей практике я сталкиваюсь в том числе со спамом, который пройдет подобные правила валидации в форме. Это будет исключительно русский текст без дефисов и пробелов. «Вбей в поисковике %поисковая_фраза_спамера%». Поисковая фраза — как правило — просто строка символов, но по ней действительно в поисковике можно найти посадочную страницу спамера с соответствующим контентом.
Простите за настойчивость, но я продолжу утверждать, что единственный метод со 100% эффективностью — это убирать UGC. :) К тому же это проще.

Спасибо за детальный ответ! Я знаю, что подобные методы очень часто используются. Моя задача была предложить предельно простую альтернативу довольно обширному набору технических мер. А именно просто выкинуть из всех шаблонов писем, которые уходят на неподтвержденные email, все переменные вида %username%, то есть весь UGC. Поверьте этот простой метод столь же эффективен, как и ваш.

Рад, что материал оказался вам полезен!

Проблема в том, что спамер «притворяется» нормальным пользователем и использует совершенно легитимные формы подписки или обратной связи. Вектор идет именно через инъекцию UGC в письмо.

Если цель спамера не доставить спам, а «подставить» сторонний домен — тогда все немного сложнее, чем просто убрать UGC из писем.
Давайте сразу оговоримся, что вряд ли какой-то мелкий сайт столкнется с атакой подобного рода, а значит сервис располагает какими-то ресурсами для митигирования проблемы.
Что можно сделать предиктивно:

• Капча, санитайзинг форм — мало эффективно, так как легко проходится, но пусть лучше будет
• Выделение регистрационных писем в отдельный сегмент. Например, с помощью X-Mailru-Msgtype — и наблюдение в Постмастере за данным сегментом
• Подписаться на получение fbl-отчетов
• Если есть время и ресурсы — рейтлимиты на форме, например, для каких-то подозрительных AS

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

В данном кейсе я должен сделать одно очень важное замечание по поводу Double Opt In. Если doi не настроен — это усугубит проблему в разы. После регистрации сразу полетят цепочки рассылок и реакция пользователей и почтовых провайдеров будет сильнее.

Спасибо за предложенный способ!
Вы описываете защиту от харвестинга со стороны злоумышленника. Сейчас это действительно может работать какое-то время. На самом деле — это уже пройденный путь на примере алгоритмов сбора email адресов «из открытых источников». На зашумление ящиков веб-мастерами (например вместо @ писать [at]) спамеры отвечали усложнением регулярок.

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

В некоторых случаях можно целые автономные системы подконтрольные спамерам находить. Но чаще всего IP-адрес меняется очень быстро. Убрать из писем UGC — на самом деле очень просто. Пару строчек поправить — и счастье. К тому же я приводил в статье ссылки на пару источников, в которых также с разных точек зрения показывается что псевдоперсонализация писем — не очень хорошо.
В любом случае — борьба с спамом — это хорошо! Рад, если предложенные мной или в комментариях методы спасут чьи-то проекты от подобной атаки.

Политика блэклистинга, безусловно, рабочий инструмент. Особенно в сочетании с хорошо прописанным санитайзингом форм, капчей и тд. Но, к сожалению, такой подход не гарантирует 100% эффективной защиты. К тому же — как и любой список — его необходимо поддерживать, затрачивая на это пусть небольшие, но ресурсы. В своей статье я дал метод, который однозначно решит проблему спама через форму подконтрольных вам ресурсов. Повторюсь приведенный мной метод решает именно проблему спама через формы. Борьба с регистрацией ботов, кликерами — это уже совсем другая история :).

Здравствуйте! Нередко условно первое письмо является очень важным для получателя. Это может быть, например, подтверждение регистрации или транзакция. Доступ к таким письмам у пользователя должен быть максимально быстрым и удобным. Но если какой-то сервис пренебрегает требованиями, например, запускает рассылки без DOI (подтверждения пользователем email'а из письма), то очень быстро его письма окажутся в папке «Спам» или вообще перестанут доставляться. К счастью, большая часть рынка сейчас очень внимательно следит за репутацией своих рассылок и следует общепринятым практикам.