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: <[email protected] > S 451 <[email protected] >... 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>'" и то, что это может привести к отказу от приема ожидаемого сообщения.