|
ru.unix
- RU.UNIX ----------------------------------------------------------------------
From : Artem Chuprina 2:5020/371.32 24 Aug 2000 13:28:23
To : alexm@hsys.msk.ru
Subject : Re: qmail question
--------------------------------------------------------------------------------
>>>>>> "AC" == Artem Chuprina <Artem_Chuprina@p32.f371.n5020.z2.fidonet.org>
ahmr> writes:
ahmr>> И что это ДиДжей имел в виду, кто бы знал??? Hадо пойти нарыть патч.
AC>> Кстати, в своем медленном и печальном чтении у него доки я так и не
AC>> нашел, где у него это описано... И где роется патч.
ahmr> Hаписано в файле THOUGHTS. Патч роется не знаю где, наверное, на
ahmr> qmail'е. Если нету -- значит, эм-иксы только в России обламываются ;)
Читаю:
If I successfully connect to an MX host but it temporarily refuses to
accept the message, I give up and put the message back into the queue.
But several documents seem to suggest that I should try further MX
records. What are they thinking? My approach deals properly with downed
hosts, hosts that are unreachable through a firewall, and load
balancing; what else do people use multiple MX records for?
То есть не отвечающего хоста это не касается? Тогда не все так плохо. Hадо
проверить, кстати. Собственно, тогда я более-менее понимаю, что имелось в
виду. Ситуация означает, что он либо перегружен, либо криво сконфигурирован.
От второго все равно мало что спасет, следующий в очереди MX все равно
"дальше" и все равно будет к данному ломиться (нет, я могу себе представить
конфигурацию, которая допускает на MX с дистанцией 10 почту только с того
хоста, который прописан с дистанцией 20, а тот уже принимает отовсюду, но если
он при этом еще и позволяет с остальных хостов коннектиться, то это криво до
умопомрачения). Про "перегружен" и наличие более "далекого" MX - а какая,
собственно, разница, где письмо будет болтаться в очереди? Кроме того, если
прямо сейчас пойти на тот MX, а он прямо сейчас же попытается прокинуть письмо
на первый, то разгрузке первого это совсем не поспособствует. А про
"перегружен" и наличие другого MX с той же дистанцией надо посмотреть на
упоминаемый им load balancing.
То есть я еще не уверен, что подход DJB правильный, но во всяком случае я вижу
в нем один плюс (он способствует разгрузке перегруженного MX) и один возможный
минус вокруг load balancing.
--
Счастливо!
Ран.
--- ifmail v.2.14.os-p7-tma3
* Origin: MemoNet (2:5020/371.32@fidonet)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
