= Сообщение: 139 из 1098 =================================== RU.FIDO.NEXTGEN =
От : Nil Alexandrov 2:5015/46 23 Jun 17 23:55:50
Кому : Sergey Chumakov 23 Jun 17 23:55:50
Тема : Вопрос по узлу
FGHI : area://RU.FIDO.NEXTGEN?msgid=2:5015/46+594d8448
На : area://RU.FIDO.NEXTGEN?msgid=2:5020/723+d61717a1
= Кодировка сообщения определена как: CP866 ==================================
==============================================================================
Hello, Sergey!
Saturday June 24 2017 00:26, from Sergey Chumakov -> Egor Lihov:
SC> Вот такую же ситуевину, как у тебя, наблюдал у знакомого,
SC> партайгеноссен Alexander Morozov. Он прояснял вопрос у N5020C и вот
SC> поднял недавно ноду на ХотдогЕде :-) Теперь он 2:5020/2880 Рекомендую
SC> обратиться за консультацией к нему :-) Ну а про не совсем чистый EON
SC> тебе уже хорошо разъяснили ;-)
Осталось разъяснить различия во флажках нодлиста EMA, IEM, IMI (и может ещё
UIC, ITX, ..)
Безопаснее всего писать IEM - бесполезно ожидать, что по такому емейлу
поймут тот или иной формат аттача, короче писать только человеку человеком.
Раньше был EMA с аналогичным смыслом (да и до сих пор полно таких записей), но
уже устарело, так что IEM.
А кто указывает IMI, то уже ожидается, что mime аттачи там примут, также все
остальные флаги говорящие о конкретном формате посылаемого по емейлу.
А вообще, пожалуй я тут вот это оставлю.
=============================================================================
* Area : NETMAIL (Личная почта)
* From : Alex Barinov, 2:5020/715 (Tuesday September 27 2016 17:15)
* To : Dmitry Panasenko
* Subj : прошу проконсультировать
=============================================================================
Приветствую Вас, Dmitry!
16 сен 16 19:11, Dmitry Panasenko wrote to R50C:
DP> Алексей, приношу извинения за беспокойство, но, чую, без тебя
DP> разрулить вопрос не получится: в конце-то концов всё равно в тебя всё
DP> упрётся, если что. :) Так что, если можно, если будет у тебя
DP> возможность сейчас ответить, то, пожалуйста, сообщи при этом явно,
DP> является ли твой ответ официальным И (конъюнкция) могу ли я его
DP> цитировать (хотелось бы просто отфорвардить твой ответ целиком в
DP> местную сисопскую эхоконференцию).
Оба раза "да".
DP> Пытался сам найти нечто навроде faq'а по данному вопросу - ничего
DP> путного найти не смог (за исключением текстов стандартов). Учитывая
DP> то, что такой же результат - и у ряда иных, известных мне, лиц,
DP> подозреваю, что такой "бумаги" до настоящего момента в природе не
DP> существует. Если ошибаюсь, прошу тыкнуть пальцем, где я бы мог взять
DP> такую "бумагу" для ознакомления и вдумчивой её проработки. :)
Бумаги, особенно для вдумчивого чтения по этому вопросу, действительно, нет, да
и не вижу в ней надобности, ибо существуют авторизованные координаторами типы
узлов и FTS (на худой конец FSP) стандарты на поддерживаемые этими узлами
протоколы. Есть раздел R50FAQ, в котором расписаны по пунктами требования ко
всем типам IP-узлов, в том числе EON. Других требований в R50 к таким узлам
нет, и NC не в праве предъявлять к таким узлам технические требования выше
изложенных в R50FAQ.
DP> Так вот. Что требуется для организации EON?
DP> Hет PSTN-линии, но есть ip-канал, хотя и только на исходящие. Есть
DP> возможность к кому уйти в даун-линки. То есть с исходящим трафиком -
DP> никаких проблем. Как и со входящим, когда он идёт по роутингу: с
DP> такого узла связался со своим аплинком и без проблем забрал почту.
Вот. И про это в R50FAQ есть специальные строки:
2. Выдача IP-only узлов осуществляется NC географических сетей на
основании 2.2 FPD. Основанием для отказа в выдаче IP узла может быть
отсутствие у NC (и уполномоченных им хабов) технической возможности
доставки нетмейла этому узлу. Под доставкой понимается получение узлом
своего нетмейла на входящих _или_ исходящих соединениях с узлом NC или
уполномоченного хаба на каком-либо из поддерживаемых ими протоколов.
То есть если забирать у аплинка почту можешь только на исходящих, NC не в праве
отказать тебе в выдаче узла. Это не значит, что у EON не должно быть
возможности получать входящую корреспонденцию, это значит, что если он по
каким-то причинам не может или не хочет воспользоваться этой возможностью, то
это не является поводом для отказа в выдаче или экскоммуникации узла.
DP> Делается e-mail (на том же mail.ru, как пример).
Именно.
DP> Дальше что?
Живёшь полноценной фидошой жизнью. :-)
DP> Можно ли увидеть пример строки для нодлиста, как следует прописывать,
DP> когда указывается только такой вот e-mail для связи и всё на этом?
Строчка оформляется в соответствии с текущими редакциями FTS-5000 и 5001:
,777,My_Station,Here,Sysop,-Unpublished-,300,CM,IEM:station@mydomen.net
Это минимальный формат: время работы - CM (обязательно для EON-узла. Это время
приёма корреспонденции на указанный в строке e-mail, а не время работы
компьютера с тоссером!) и, собственно, адрес для отправки кореспонденции на
узел.
DP> А то лично я что-то толком, в числе прочего, с нынешними флагами не
DP> разберусь: следует ли использовать для таких случаев флаг IEM (и
DP> достаточно ли его одного)?..
С моей точки зрения как R50C - достаточно. Поддержка автоматизированных
EON-протоколов (TransX или SEAT) - опция.
DP> а то, как посмотрю на строчки в
DP> действующем нодлисте, в аналогичных случаях (также единственным
DP> флагом) используется EMA (или этот флаг здесь - ни к селу, ни к
DP> городу)?
EMA - древний флаг, давно убранный из стандартов. Теперь остался только IEM.
DP> Далее. Пусть сделан e-mail, такой узел (так или иначе) уже прописан в
DP> нодлисте, установлен линк с аплинком (на исходящих на аплинка от
DP> такого узла). Hекое лицо (да хотя бы за-ради теста) направляет на
DP> такой e-mail - e-mail-сообщение, содержащее приаттаченный pkt,
DP> содержащий сообщение с приснопамятной троицей флагов (ARq, RRq, Cfm).
DP> Как следует поступать дальше?
Если у тебя с человеком нет парольного линка, то как с любой непарольной
корреспонденцией - разберу когда дойдут руки. Правда, с моей точки зрения, руки
должны доходить не реже раза в месяц, так как письмо может быть от NC
проверяющего твою живость, и неответ в течение месяца может быть расценен как
признак дауна узла со всеми вытекающими.
DP> Из твоего с Гремлином недавнего обсуждения в r50.sysop, я делаю вывод,
DP> что просто в ответ с e-mail'а на e-mail отправить e-mail-сообщением
DP> нечто вида "Ваше сообщение получено" недостаточно (и вообще не нужно).
DP> Это так?
Hаше разногласие с Гремлином состоит в том: необходима ли на EON железяка
(фактически, тоссер), автоматически отвечающая на флаги хотябы раз в сутки или
нет, и за частоту обработки входящего нетмейла отвечает сисоп как человек. Я за
второй вариант, ибо исправно отвечающая железяка в отсутствии сисопа никак не
поможет решить проблемы, возникшие с узлом, о которых пишет Гремлин.
DP> Ладно. Руками (пусть так) этот/эти pkt были выковыряны, брошены в
DP> инбаунд, растоссены.
DP> Hо ведь штатно итоговые "квитки" далее пойдут по роутингу. Достаточно
DP> ли такого?.. а ведь где-то далее на транзитных узлах может быть и
DP> "затык".
Собственно, как и при ответе на мыло, залитое дирректом обычным мейлером, если
не приложить специальных усилий.
DP> Либо же обязательно требуется создать такие итоговые "квитки" с флагом
DP> директ, выковырять их из аутбанда и отправить на e-mail запросившего
DP> их лица - со своего e-mail'а, указанного в нодлистовой строчке,
DP> приаттачив их к созданному e-mail-сообщению?
Такое требование есть только для узлов с флагами ISE, ITX, поддерживающих
соответствующие протоколы. В этом случае специальные мейлеры делают описанную
процедуру автоматически.
DP> Можно, конечно, попытаться и по ip отослать напрямую на тот узел
DP> ответные "квитки", если запросивший их узел (согласно информации из
DP> своей строчки в нодлисте) принимает входящие по ip. Такое можно
DP> сделать как дополнение к ответу на e-mail, либо же это носит
DP> исключающе альтернативный характер (достаточно и одного такого способа
DP> ответа)?
Это исключительно добрая воля сисопа, желающего поднять reliability своего
узла.
DP> И какой временной интервал предоставляется для направления (тем или
DP> иным способом, "тем или иным" - это если и "по роутингу" также можно)
DP> такого подтверждения (этих "квитков")? 12 часов?
Для узлов с флагами ISE, ITX FTS-5001 отводит 24 часа на такую реакцию. Для
остальных ничего такого не оговорено.
DP> Тут попутно возникает ещё и вот какой вопрос. Hекто "А" направляет
DP> некому "Б" такой вот приаттаченный pkt. Далее - тишина. Этот "А"
DP> заявляет, что тот "Б" - нарушает требование. Hа что от "Б" следует
DP> встречное утверждение: этот "А" меня оговаривает, никаких сообщений
DP> "Б" от "А" получено не было. А ведь действительно может быть и так -
DP> "А" ничего не направлял. Так какой "документ" должен представлять "А"
DP> в подтверждение того, что он действительно направлял то сообщение?
Лог отсылки сообщения на свой SMTP/IMAP сервер. Чисто теоретически можно
запросить от провайдера лог общния его почтового сервера с почтовым сервером
получателя, но это из раздела фантастики. :-)
Также важными уликами являются отлупы сервера получателя.
DP> В
DP> случае с PSTN/ip, насколько понимаю, всё проще: представляется
DP> выдержка из лога мэйлера, из которой чётко видно - была ли вообще
DP> попытка "достучаться" (и куда именно), а если была, была ли успешной
DP> сессия (была ли передана информация), либо же узел адресата не
DP> откликнулся. Если же и ныне можно что-то подобное представить, тогда
DP> получается (фактически, а не формально), что отсылка "квитков" - это
DP> дополнительное требование, фактически излишнее (понятно, что если есть
DP> закреплённая такая обязанность, то можно говорить лишь о "фактической"
DP> стороне вопроса, но не о "формальной": что называется, начальник
DP> сказал "хорьк", значит - "хорьк" и никаких "сусликов").
Моя позиция по алгоритму директному общению с EON-узлом такая:
1) Если узел по флагам поддерживает протоколы с автоматическим квитированием,
то всё строго в соответствии с FTS-5001 и соответствующими стандартами.
2) Если узел без специальных протоколов и за разумное время (разумность
определяется экстренностью ситуации, если ничего экстренного - месяц) не
получено ни ответа от сисопа, ни отлупа от почтовых серверов, ни квитков
обработки корреспонденции, пишем NC узла проверить работоспособность EON. До
истечения месяца допустимо продублировать корреспонденцию через аплинка и
обычным e-mail-ом на нодлистовый адрес. Вполне возможно, аттач потерялся где-то
на серверах или его молча прибила какая-то параноидальная антиспамерская
приблуда.
Да, конечно, идеальны с точки зрения reliability - узлы ISE/ITX, но это
означает требование хотя бы раз в сутки включать узел и обрабатывать входящую
почту, что для потенциальных возвращенцев не всегда приемлемо.
Алексей Баринов
E-Mail: bav (at) sirena-travel.ru ICQ: 24466689 Skype: huba-huba
[Team Бородатые]
-+- GoldED+/W64-MSVC 1.1.5-b20160322
+ Origin: Alex at Work (2:5020/715)
=============================================================================
Best Regards, Nil
--- GoldED+/LNX 1.1.5
* Origin: -=NIL BBS=- (2:5015/46)
|
