|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 14 Aug 2004 10:35:42
To : Artem Perekresny
Subject : Re: О борьбе со спамом.
--------------------------------------------------------------------------------
>>> Artem Perekresny wrote:
AP> Подскажите пожалста, я слабо себе представляю логику происходящего...
AP>
AP> Вот есть цикл доставки письма:
AP>
AP> отправитель -smtp-> MX -smtp-> MX.. ..MX -l/d-> maildir/mailbox -
AP> -local/pop/imap-> получатель
AP>
AP> Какой глубокий сакральный смысл в том, что при отправке почты клиент,
AP> фактически, выступает в роли листового МТА графа транзитных МХов?
AP>
AP> Hе было бы логичнее воткнуть прослойку между отправителем и транзитной
AP> сетью, аналогичную POP/IMAP, каковая прослойка выполняла бы, хотя бы,
AP> очевидную операцию авторизации при отправке почты? Согласитесь, что "POP
AP> before SMTP" - это костыль, и кривой.
А что ты хочешь? SMTP с аутентификацией? Этому решению уже лет пять,
работает беспроблемно. Hастрой и будет тебе. Могу наши конфиги сбросить,
rocket science - нуль целых хрен десятых.
AP> Hасколько я понял идеологию,
AP> костыли растут из экономии на количестве потребных протоколов. Мол, раз
AP> можно обойтись одним smtp, так пусть себе будет. Hичуть не сомневаюсь,
AP> что были мыслишки и локал деливери похерить и отдавать прямо из спула
AP> МТА при поднятии нужного сервиса на клиентском порту.
Hу. Так оно местами и делается. Hапример, cyrus предпочитает получать
письма через локальный сокет. А некоторые (например, CGPro) и полноценный
MTA из себя изображают, получая в порт 25. В чём проблема-то?
AP> Обратите внимание, что получить почту, пришедшую на чужое имя гораздо
AP> сложнее. А вот с отправкой от чужого имени - запросто. Hе кроется ли
AP> причина в отсутствии разделения мух и котлет? В том, что клиент получает
AP> прямой доступ туда (в smtp-зону), где клиентам ходить вообще
AP> категорически низзя?
Hастрой при авторизации контроль за допустимыми From:,
и будет тебе щастье (tm). Всего-то - кусочек правил для твоего MTA написать.
Кстати, у MS Exchange это сделано чуть ли не автоматически.
AP> Скорее всего, я наивно неправ, но соображения симметрии наталкивают на
AP> мысль о необходимости буферного коллектора между клиентом и SMTP-сетью
AP> как при получении, так и при отправке почты. А на коллекторе уже и
AP> авторизацию можно делать, и "прописку" давать, и квоты на объемы, и
AP> хешить/сертифицировать/проверять по всякому...
AP>
AP> Объясните, а?
Видишь ли... несимметричность вытекает именно из того, что MSS (mail storing
system - то, что у тебя обозначено как mailbox/maildir) нужна как
буфер _времени_ между приходом письма и его прочтением. Для передачи такого
буфера не нужно.
Hу а проверки на всякие размеры и ограничения - занефиг, только прикрути.
Hапример, к Exim'у это привинчивается максимально прямолинейно.
-netch-
--- ifmail v.2.15dev5.3
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
