sender verification в MTA

Забей, пусть эти идиоты без почты от тебя сидят.

В том-то и фигня, что на днях в этом был замечен даже RIPN.

Да не может быть!

3. В связи с растущей популярностью этой проверки хотелось бы знать, как её чаще всего реализуют (конфиги? внешние скрипты? к каким MTA обычно прикручивают?).

К sendmail есть milter-sender & smf-sav.
А также используются самописные call-back'и.
Насколько часто они используются - не скажу.

С postfix & exim дела не имею, но по всей видимости для них call-back делается простым редактированием конфига, и поэтому, наверное, их call-back'и используются чаще:
require verify = sender (exim)
или
verify_sender = reject_unverified_sender (postfix)

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

Минусы call-back'a:
1) спамер может использовать реальный адрес любой почтовой системы в качестве адреса отправителя (т.е. проверка будет успешной);

2)почтовые шлюзы не обязаны знать о существовании пользователя в системе, с которой данный шлюз пересылает почту во внешний мир, а callback будет сделан именно на шлюз (наверное, это зависит от технологии конкретного call-back'a, к кому он сделает запрос);

3)(с конфы senmail'a): "... milter-sender and equivalent filters do a "MAIL From" and a "RCPT TO" commands to verify that user exists. If sendmail answers "220 OK". It considers that users exists. But when sendmail answers "OK", this *** doesn't means that user exists ***, but only that sendmail says : "OK, I can accept messages for this user ...

4) ...So, consider the consequences using this option : a spammer sends 10000 messages to 10000 different addresses using as forged sender address a...@priv.onet.pl. If all spam recipients servers are using milter-sender, you, the innocent, will receive 10000 little messages with the subject "mailbox check"... "
5) сервер-отправитель может принять вас за спамера, особенно если адрес отправителя действительно не существует, и внести вас в свой "черный список" или, что еще хуже, в какой-либо dnsbl.

6)http://www.opennet.ru/openforum/vsluhforumID1/84898.html#14
Для некоторых доменов данная проверка вообще не имеет смысла, например для домена mail.ru, ответ всегда будет положительным. Так что для снижения нагрузки следует вносить в исключения домены, которым вы доверяете или для которых адрес отправителя нельзя проверить.

7) http://www.opennet.ru/openforum/vsluhforumID1/84817.html#12
У меня были проблемы с теми серверами, которые используются для отправки почты от несуществующих пользователей, например, рассылка, подтверждение регистрации и т.д. Для них нужно делать исключения...
плюс на них уходит время и при прочих равных сервер обслуживает меньшее число клиентов.
лично я использую callout только для списка наиболее часто используемых спамерами доменов

Благодарю за развёрнутый ответ на третий вопрос! :)
Как и зачем Вы используете это дело - понятно.

Остаются ещё полтора:
>> 1. Что происходит при зацикливании таких верификаторов? Что если оба-два почтовых сервера в цикле начинают заниматься "верификацией друг друга"?

Я так понимаю, приходится вписывать в исключения сервера с callback'ом.
Интересно. Это что же, постоянно логи изучать? )

>> 2. Какого хрена бОльшая часть таких верификаторов сама не пишет ничего в MAIL FROM: во время callback'а?

Вот ваш
> К sendmail есть milter-sender & smf-sav.
что пишет в MAIL FROM: во время callback'а ?
А экзим и постфикс?
А то может никто этим не заморачивается, и пора писать багрепорты/фичреквесты в проекты? )

Как и зачем Вы используете это дело - понятно.

Сорри, я не использую, просто мне приходилось «выяснять отношения» с использующими call-back'и админами по поводу несправедливых отказов в приеме почты. Поэтому и была собрана данная информация.

2. Какого хрена бОльшая часть таких верификаторов сама не пишет ничего в MAIL FROM: во время callback'а?

Не знаю, возможно, здесь расчет на то, что почту от <> по RFC отвергать нельзя. И , возможно, адрес <> включен в список исключений, чтобы не происходило зацикливаний, о которых вы пишете.

> возможно, здесь расчет на то, что почту от <> по RFC отвергать нельзя. И , возможно, адрес <> включен в список исключений

Благодарю за идею. Думаю, так оно и есть. Спасибо.

Я не придурок у меня exim делает callout проблем нет.
Mail from: <> т.к. по rfc821 такие письма должны приниматься (рекомендовано), можно установить другое значение. Для пустого отправителя предполагаю callout не делается поэтому нет зацикливания.