Entry tags:
А постмастеров, у которых первичный релей сначала принимает письма на несуществующие адреса
а потом генерирует баунсы, надо убивать в детстве.
Наглядный пример: relay.ciscom.ru. У них этот релей вообще единственный.
Наглядный пример: relay.ciscom.ru. У них этот релей вообще единственный.
no subject
no subject
no subject
no subject
no subject
если бы над вопросом задумались - может что-нибудь и придумали бы. Но в данном случае никто не стал париться и просто придумали включить приём всех писем. малацы, фигли.
no subject
Сделать telnet exch 25, MAIL FROM: postmaster@main.doma.in, RCPT TO: recipient@doma.in, read reply просто нереально
no subject
no subject
no subject
раз в полчаса обновлять список реципиентов кроном
no subject
no subject
зачем оно надо, когда можно или кроном апдейтить список, или вообще, при добавлении юзера прогонять на МТА скрипт который берет список из активдира
no subject
а остальное - вопрос эффективности. иногда действительно проще скопить пачку писем на релее, а потом заслать их все в exchange за одну сессию.
no subject
no subject
no subject
no subject
no subject
no subject
no subject
И волосы будут лёгкими и шелковистымиno subject
no subject
Для всяких адванснутых юниксовых мультисервисных конфигов - тоже достаточно просто, потому что всё понятногде лежит.
no subject
во всяком случае я плохо представляю размер бедствия при котором у меня бы в exch адреса появлялись или исчезали со скоростью "раз в пять минут"
no subject
no subject
приходят обычно с утра (чаще всего - в понедельник)
список приходящей пачки известен заранее, и прислан админам тоже заранее (на то есть отдел по борьбе с персоналом)
но даже если нет - пока человеков водят оформлять всякие бумажки и пропуска, время у меня будет...
да и первая почта в 99% случаев будет внутренней рассылкой
no subject
Нененене, Дэвид блейн. Потом получится "адреса есть в эксче но нету на фронтенде", "адреса есть на фронтенде но нету в эксче" и прочие веселья.
Крон там не лишний, но если не хочется таскать всё слишком часто - ну, храни предыдущую версию транспортного файла, если нет изменений - не клади на мх.
no subject
ну и для меня плюс в том, чтоб иметь адрес внутри, недоступный снаружи
ну и само-собой хранение предыдущего файлика...
no subject
А если нет - лучше бы все неинтеллектуальные таски, просто скриптуемые - скриптовать.
no subject
хотя, конечно, путь верный...
no subject
А имеющий мозг админ - очень быстро понимает прелести скриптования.
no subject
а что ужасного?
Re: а что ужасного?
вместо того, чтобы сразу ответить спаммерскому хосту "пшел вон, нет у меня такого адреса", оно принимает письмо, а потом генерирует баунс. но не спаммеру, которого фиг вычислишь, а ни в чём не виноватому владельцу адреса, который спаммер указал в envelope-from.
после массовой рассылки спама и последующего получения сотен баунсов желание убивать криворуких уродов появляется даже у самых мирных людей.
Re: а что ужасного?
Re: а что ужасного?
"If an SMTP server has accepted the task of relaying the mail and
later finds that the destination is incorrect or that the mail cannot
be delivered for some other reason, then it MUST construct an
"undeliverable mail" notification message and send it to the
originator of the undeliverable mail (as indicated by the reverse-
path)."
Re: а что ужасного?
согласен в принципе
а вот зачем люди напрягают свои бэк-енд серверы такой ерундой, вместо того, чтобы отсекать их на первых же relay-ах я действительно не понимаю
интересно, а как правильно сочитать грейлистинг и проверку получателя? сначала отгрейлистить, а потом послать с user unknown? или сразу слать лесом?
Re: согласен в принципе
при чём тут свой постмастер и его спам-фильтр, я вообще не понял. мой постмастер не виноват, что от моего имени рассылают спам, и что с криво настроенных серверов мне присылают баунсы. он их принимает, и правильно делает.
если вы хотите увеличить нагрузку на сервера, то можно сначала грейлистить, а потом уже посылать. но я не вижу причин это делать. грейлистинг предназначен для отсечения однократно отправляемого спама, он отсечётся и на 4xx, и на 5xx, а ваш сервер будет тратить свои ресурсы на запоминание попыток отправки писем на несуществующие адреса. а для валидных писем, по ошибке отправленных на несуществующий адрес, это только вызовет ненужную задержку перед получением квитанции.
Re: согласен в принципе
Re: согласен в принципе
тогда пардон