RFC 2505 — Рекомендации по предотвращению спама для SMTP MTA

3.2. Персональные фильтры спама

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

Следовательно, единственным приемлемым решением является разрешение на использование персональных антиспамовых фильтров. Такие фильтры подобны описанным выше, но применяются и настраиваются каждым пользователем независимо. Поскольку большинство пользователей не имеет четкого представления о том, что следует делать (за исключением единодушного желания избавиться от спама), почтовой системе следует обеспечивать принятый по умолчанию набор правил и предоставлять каждому пользователю возможность изменения этих правил для себя. В среда типа UNIX это может выглядеть примерно так:

/etc/mail/rc.spam
~/.spamrc

К этому добавляются правила взаимодействия между первой и второй конфигурацией.

Все это создает достаточное количество нерешенных проблем. Например, следует ли разрешать пользователям самим задавать коды возврата SMTP, как описать эти коды для несведущего пользователя и как существующие почтовые системы будут разбираться с возвращаемыми от пользователей кодами, особенно в тех случаях, когда вперемешку возвращаются коды 5xx и 4xx, как показано ниже:

C  MAIL From: <[email protected]
>
S  250 <[email protected]
>... Sender ok
C  RCPT To: <[email protected]
>
S  250 <[email protected]
>... Recipient ok
C  RCPT To: &lt;[email protected]
&gt;
S  451 &lt;[email protected]
&gt;... Denied due to spam list
C  RCPT To: <[email protected]
>
S  550 <[email protected]
>... Denied due to spam list

Естественно, что можно ограничиться кодами "250 OK" или "550 Denied", не предоставляя пользователям других вариантов, но и в этом случае возникает вопрос, как объяснить рядовому пользователю значение "Refuse 'MAIL From: <.*@spam.example>'" и то, что это может привести к отказу от приема ожидаемого сообщения.