А постмастеров, у которых первичный релей сначала принимает письма на несуществующие адреса

[dil]

а потом генерирует баунсы, надо убивать в детстве.

Наглядный пример: relay.ciscom.ru. У них этот релей вообще единственный.

Comments

[3apa3a-b-ta3e.livejournal.com]

я как-то по глупости и молодости так сделал. больше не буду.

[dil.livejournal.com]

ну по молодости и глупости у всех ляпы бывают. но чтобы это в production системе было..

[3apa3a-b-ta3e.livejournal.com]

Было, было. Ибо так было в проекте написано.

[dil.livejournal.com]

тогда убивать авторов проекта

[3apa3a-b-ta3e.livejournal.com]

ситуация была такая - mx в dmz, который принимает почту, а потом скидывает её на внутренний exchange. между exchange и mx`ом разрешён только DST 25 tcp. и откуда mx`у брать список внутренних реципиентов?

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

[gvj.livejournal.com]

Ну да, ну да.
Сделать telnet exch 25, MAIL FROM: postmaster@main.doma.in, RCPT TO: recipient@doma.in, read reply просто нереально

[3apa3a-b-ta3e.livejournal.com]

на самом деле проще (и я думаю - правильнее) разрешить mx`у делать ldap-запросы к GC и уже оттуда плясать. у меня сейчас так и сделано.

[dil.livejournal.com]

синхронный режим доставки у релея - на ходу спрашивать у exchange, есть ли у него такой адресат

[tullamoredew.livejournal.com]

неэффективно
раз в полчаса обновлять список реципиентов кроном

[dil.livejournal.com]

чего это неэффективно? всё равно большинство писем туда отправлять, почему бы не прямо сразу?

[tullamoredew.livejournal.com]

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

[dil.livejournal.com]

почему сессии разные? принимаемое письмо прямо сразу пытаемся скормить в exchange. если он ругнулся на адрес получателя - ругаемся в строну отправителя, не ругнулся - выполняем остальные проверки. если они успешно прошли, отправляем остаток письма в exchange, не выполнились - говорим exchange'у RSET, в клиента ругаемся соответствующей ошибкой.

а остальное - вопрос эффективности. иногда действительно проще скопить пачку писем на релее, а потом заслать их все в exchange за одну сессию.

[tullamoredew.livejournal.com]

а разве попытка скормить ксченджу нерелевантные письма не beats the whole purpose of a front end MTA?

[dil.livejournal.com]

зависит от этой самой purpose. если frontend relay только затем, чтобы не выставлять exchange в открытый интернет, то всё нормально.

[tullamoredew.livejournal.com]

http://thelowedown.wordpress.com/2008/02/16/postfix-gateway-to-exchange/

[dil.livejournal.com]

да не, ну понятно же, что если захотеть, то проблема решаема :)

[tullamoredew.livejournal.com]

как впрочем и любая проблема :)

[3apa3a-b-ta3e.livejournal.com]

дык уже. сейчас. у меня лично.

[dma.livejournal.com]

класть на mx из внутренней сети файлик с реципиентами. Хоть раз в 5 минут, хоть раз в час - разницы нет. И волосы будут лёгкими и шелковистыми

[dil.livejournal.com]

в общем, тоже метод, но файлик иногда нетривиально сгенерировать. там же не только личные адреса должны быть, а еще и групповые, и алиасы..

[dma.livejournal.com]

Для эксченджа этот файлег генерируется тривиальнейшим образом. "Всё, что имеет смтп-адрес" есть в тамошнем лдапе.
Для всяких адванснутых юниксовых мультисервисных конфигов - тоже достаточно просто, потому что всё понятногде лежит.

[zeleny.livejournal.com]

имхо - крон тут лишний... access менять по факту изменения в AD надо (ручками, ага)...

во всяком случае я плохо представляю размер бедствия при котором у меня бы в exch адреса появлялись или исчезали со скоростью "раз в пять минут"

[dil.livejournal.com]

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

[zeleny.livejournal.com]

точно так и есть... компания небольшая правда, но:
приходят обычно с утра (чаще всего - в понедельник)
список приходящей пачки известен заранее, и прислан админам тоже заранее (на то есть отдел по борьбе с персоналом)
но даже если нет - пока человеков водят оформлять всякие бумажки и пропуска, время у меня будет...
да и первая почта в 99% случаев будет внутренней рассылкой

[dma.livejournal.com]

РУЧКАМИ????

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

[zeleny.livejournal.com]

ручками. по регламенту: "пользователь создан, ящик создался, в бэковые списки рассылки добавлен. на фронт добавлен. письмом снаружи проверен. на воркстейшне аутлук настроен. таск закрыт"

ну и для меня плюс в том, чтоб иметь адрес внутри, недоступный снаружи

ну и само-собой хранение предыдущего файлика...

[dma.livejournal.com]

Ну, если есть задача задрочить почтового админа - тогда конечно ВСЁ ручками.
А если нет - лучше бы все неинтеллектуальные таски, просто скриптуемые - скриптовать.

[zeleny.livejournal.com]

гм.. переименовать постмастера в перлмастера? оверхед, помоему...
хотя, конечно, путь верный...

[dma.livejournal.com]

Ну... постмастер - он обязан иметь мозг.
А имеющий мозг админ - очень быстро понимает прелести скриптования.