Вашему вниманию предлагается гейт fido<->internet, поддерживающий
гейтование как личной почты (netmail), так и эхоконференций.

   Быстрый способ инсталляции описан в файле INSTALL.

   Несколько замечаний.
   - чтобы сделать интернетовскую конференцию в fido r/o, нужно завести
локального пользователя и описать его как newsserver для этой эхи, а
его почтовый ящик просто удалять при возникновении.
Другой вариант - поставить соответствующие привелегии в эхопроцессоре.
   - чтобы сделать фидошную эху в интернете r/o, нужно просто на нее не
подписываться на узле. Вариант с эхопроцессором также подходит.
   В обоих случаях вариант с привелегиями в эхопроцессоре мне кажется более
предпочтительным, т.к., во-первых, вы можете себе оставить возможность
писать письма и, во-вторых, по bad-ам вы сможете увидеть попытки написать
в r/o конференцию.

   Параметр seen-by стОит включить, если возможно двойное гейтование и
при этом Вы отдаете (и берете) гейтуемые конференции по ftn-сети. Если
же Вы гейтуете почту только для себя (чтобы читать конференции из golded)
и никому другому их не отправляете, то этот параметр лучше выключить,
чтобы не засорять заголовки usenet-сообщений. В случае получения/отправки
почты через news-server этот параметр значения не имеет. Поэтому _очень_
не рекомендуется отдавать кому-то гейтуемую почту, получаемую от ньюс-
сервера (а не по cnews) - он обрезает все служебные поля (message-id,
path, seen-by), считая их ненужными (для internet это действительно так),
в результате очень повышается вероятность дупов (неотлавливаемых!).

   При гейтовании модерируемых конференций им необходимо дать параметр
/feed в строке group, и там же указать адрес mailnews-сервера для того,
чтобы при написании письма из fido сервер отправил его модератору, а не в
badmail, как произойдет при отправке по cnews. Принимать их при этом можно
и по cnews.

   Если вы хотите свою личную интернетовскую почту читать фидошным редактором,
нужно в своем домашнем каталоге поместить файл forward, состоящий только
из вашего фидошного адреса, как он виден из интернета, и прописать себя
в поле chaddr в gate.conf. В этом случае приходящая личная почта будет
переправляться на адрес, написанный в файле forward, далее гейтоваться
и попадать в netmail folder. При ответе письмо будет гейтоваться в
relcom с заменой вашего адреса на обычный интернетовский, и ваш корреспондент
не будет испытывать никаких неудобств (а если нет tearline, то и вообще
не заметит, что вы ему отвечали из фидошного редактора).
   Для обратной возможности (чтение фидошной почты интернетовским
редактором) Вам нужно прописать в файле forward.cfg строки типа
forward 2:463/68 2:463/68.128 "Pavel Gulchouck" gul@gul.kiev.ua
forward 2:463/68 2:463/68.128 "Yutta Gulchouck" yutta@k-i-s-s.kiev.ua
forward 2:463/68 2:463/68.128 "" postmaster@gul.kiev.ua
(по строке для каждого пользователя) и вставить вызов forward перед
запуском fido2rel (а лучше еще и по приходу почты).

   При гейтовании из fido обратный адрес строится следующим образом:
Firstname_Lastname@[p{p}.]f{f}.n{n}.z{z}.{domain} (Firstname Lastname)
где:
Firstname Lastname - имя сисопа,
{z} - зона
{n} - сеть
{f} - узел
{p} - поинт
{domain} - домен, прописанный первым в gate.conf.
В квадратных скобках прописаны части, могущие отсутствовать (нулевой поинт
не пишется).
   Например, адрес Pavel Gulchouck 2:463/68 будет выглядеть из интернета как
"Pavel_Gulchouck@f68.n463.z2.fidonet.carrier.kiev.ua (Pavel Gulchouck)", если
в списке доменов первым идет fidonet.carrier.kiev.ua. Если в имени сисопа
присутствует символ '@', то оно просто переносится в поле from без изменений.
   При гейтовании из интернета как фидошный исходящий адрес ставится адрес
гейта (указанный первым в gate.conf), как имя сисопа указывается его
uupc-адрес, а первой строкой письма пишется "RealName: Его Реальное Имя",
если таковое есть в заголовке. Если uucp-адрес слишком длинный и не
помещается в поле from заголовка, то в заголовок пишется "From: uucp",
а в начале письма - "From: <long_address>". В этом случае не гейтуются
поля аттрибуты RRQ и CFM (т.к. они все равно не попадут по назначению).
Определяется случай повторного гейтования и если uucp-адрес оказывается
фидошным, он разбирается и прописывается в заголовок вместо адреса гейта.
При установленном параметре golded=yes вместо строки Realname пишется
клудж "\1RFC-From:" со строкой "From:" из заголовка. В этом случае GoldEd
начиная с версии 2.50 (вроде бы) показывает все довольно красиво.
   Теперь про поле To.
   При гейтовании в фидо разбираются следующие форматы адреса:
Firstname{_|.}Lastname@[p{p}.]f{f}.n{n}.z{z}.{domain}
[Firstname{_|.}Lastname%][{z}.]{n}/{f}[.{p}@{domain}
где:
Firstname Lastname - имя сисопа (по умолчанию SysOp),
{z} - зона (по умолчанию зона, в которой происходит гейтование)
{n} - сеть
{f} - узел
{p} - поинт (по умолчанию 0)
{domain} - любой из доменов, прописанных в gate.conf
{_|.} - любой из символов '_' или '.'
В квадратных скобках указаны необязательные параметры, при их отсутствии
берется умолчание. В имени сисопа '.' заменяется на пробел только в том
случае, если нет ни одного '_'.
   Например, мне можно из интернета писать на (кроме приведенного выше
адреса)
Pavel_Gulchouck@p0.f68.n463.z2.fidonet.org (если попадет на нужный гейт)
Pavel_Gulchouck%2.463/68.0@fidonet.carrier.kiev.ua
463/68@fidonet.carrier.kiev.ua (прийдет на имя SysOp)
gul@gul.kiev.ua   ;-)
   Но это все ни к чему, т.к. достаточно знать один (любой) формат адреса и
его использовать, а лучше просто отвечать на адрес, указанный в поле From
письма, на которое отвечаете.
   Для гейтования сообщений об ошибках в доставке письма, отправляемых
обычно по бэнговому адресу из поля "From ", поддерживаются также адреса
типа gul.kiev.ua!fidonet!f68.n463.z2.fidonet.org!Pavel_Gulchouck
или gul.kiev.ua!fidonet!463/68, хотя я очень не рекомендую
использовать их в нормальной ситуации.

   Из fido в relcom писать несколько проще: как фидошный адрес указывается
адрес гейта (любой), а в поле to пишется uucp-адрес. Если он туда не
помещается, то в заголовке пишется "To: uucp", а первой строкой письма -
"To: <long_address>".

       Темплейты.
       
Если строка начинается с @if, @else, @endif, @ifdef, @ifndef, @elsif,
@set, @text, @vars или для badaddr-tpl @header - это служебная строка.
Все остальные строки, начинающиеся с символа '@' игнорируются и могут
быть использованы как комментарии. Вместо @text подставляется текст
оригинального письма, вместо @header - его заголовок.
Строка @if имеет вид
@if [not] <line1>==<line2>
например,
@if [reason]==binary
или
@if not "[tomaster]"=="yes"
Строки сравниваются ignore case. Строка
@ifdef <var>
эквивалентна
@if not "<var>"==""
ну а
@ifndef <var>
эквивалентна
@if "<var>"==""
Кроме того, возможно сравнение с маской или с регулярным выражением
при помощи операции "=~", например,
@if [fromaddr] =~ MAILER-DAEMON@*
или
@if not [reason] =~ /^itwit-(to|from)$/

Строка @set имеет вид
@set <var>=<string>
Строка <string> может быть заключена в кавычки. Например,
@set GateName="Fido<->Internet Gate"
В тексте (в т.ч. в служебных строках) все подстроки типа [var] заменяются
на значение переменной var, или выкидываются, если такой переменной нет,
если только не установлено "@vars no". Регистр букв в именах переменных
роли не играет. Присвоить или изменить значение переменной можно при
помощи @set. Все подстроки `cmd` заменяются на stdout команды cmd,
например, "domain=`hostname`". Если строка заканчивается на '%',
следующая строка считается ее продолжением.
Все сказанное выше относится и к файлу gate.conf, с той
разницей, что символ '@' в начале строки не нужен. В темплейтах
обрабатываются последовательности \n, \r, \t, \s, \%, \[, \`, \\ (в gate.conf
под MSDOS и OS/2 это не так, потому что символ '\' часто встречается в
путях. В gate.conf вместо символа '[' нужно писать '[[]', вместо '`' -
'[`]'). Можно также установить в темплейте "@vars no" (в gate.conf -
"vars no"), и тогда до "@vars yes" подстановка переменных производиться
не будет, квадратными скобками в этом случае можно пользоваться как
обычно, не заменяя '[' на '[[]'. Если в любом темплейте присвоить
какое-либо значение переменной DontSend, письмо не будет отправлено.
Для reject-tpl и badaddr-tpl есть возможность отправлять сообщения еще
и гейтмастеру. Т.о. шлется два письма по одному темплейту, но для письма
гейтмастеру выставляется переменная ToMaster=yes, которую можно
использовать, например, чтобы не пересылать мастеру текст самого письма,
а только заголовок. В этом случае фрагмент темплейта будет выглядеть так:
@if not "[ToMaster]"=="Yes"
@text
@endif

Значение переменной может браться из командной строки (ключ -d) или
из environment. Кроме того, существуют переменные

OS         - "OS/2" или "MSDOS";
Module     - "Fido2Rel", "Rel2Fido" или "Attuucp".

Предопределенные переменные для всех темплейтов:

Subject    - строка subject создаваемого письма (ее можно переопределять);
OldSubject - строка subject оригинального письма;
Size       - размер оригинального письма в байтах;
LocalDate  - текущая дата в формате "01 Jan 96";
LocalTime  - текущее время в формате "00:04:01";

Для reject-tpl:
GateName - поле from создаваемого письма (можно менять); по умолчанию
           "FTN->Internet Gate";
GateAddr - адрес from создаваемого письма (можно менять);
ToAddr   - адрес To оригинального письма;
ToName   - Internet-address, куда пытались отправить письмо;
FromAddr - адрес To оригинального письма;
FromName - имя From оригинального письма;
MastName - имя гейтмастера;
MastAddr - FTN-адрес гейтмастера;
Date     - Поле Date оригинального письма;
Reason   - причина отлупа. Возможные значения:
           binary      - попытка отправки uucode, когда это запрещено,
           size        - превышение допустимого размера письма,
           twit        - FromAddr попал под параметр twit в gate.conf,
           destination - ToName не описан как send-to либо описан как no-send,
           noaddress   - не задан internet address;
           attach      - попытка гейтования аттача, когда это запрещено;
           external    - так сказал fido2rel-chk.

Для held-tpl:
GateName, GateAddr, Date имеют то же значение, что в reject-tpl; GateName
по умолчанию "Internet->FTN Gate";
FromName   - имя отправителя письма (может быть не определено);
FromAddr   - Internet-address отправителя;
ToName     - имя To получателя;
ToAddr     - FTN-адрес получателя;
Uplink     - FTN-адрес системы-аплинка (для гейта, т.е., как правило, это
             адрес гейтмастера);
Reason     - причина, по которой файл лежит на hold-е. Возможные значения:
             size       - письмо слишком большое;
             attach     - пришел file attach;
FileName   - (при [reason]==attach) - имя приаттаченного файла;
FilePath   - (при [reason]==attach) - путь на диске к приаттаченному файлу;
StoreFileName - имя, под которым файл лежит на диске;
Message-Id - ID захолженного письма или аттача.

Для badaddr-tpl:
From     - адрес отправителя оригинального письма (из "From:");
Sender   - адрес отправителя оригинального письма (из From_);
Gate     - gate internet address. По умолчанию - MAILER-DAEMON@local.domain,
           где local.domain - ваш uucp-домен (можно изменять);
Master   - internet-address гейтмастера;
To       - адрес назначения оригинального письма.
Reason   - причина отлупа. Возможные значения:
           BadAddress  - некорректный адрес To;
           TooManyHops - too many hops (-;
           ITwit       - адрес From попадает под itwit;
           ITwit-To    - адрес в строке "To:" попадает под itwit-to;
           ITwit-From  - адрес envelope-from (из From_) попадает под itwit-from;
           ITwit-Via   - в пути присутствует хост, описанный как itwit-via;
           FileAttach  - письмо содержит файлаттач при decode-attach=deny;
           TooLarge    - размер письма больше holdsize при holdhuge=no;
           External    - так сказал rel2fido-chk.
Boundary - Случайная строка (используется при multipart).
Multipart- Создавать отлуп как text/plain, или как multipart/report.
           По умолчанию multipart=no, т.е. создается text/plain,
           хотя если template не указан совсем, будет сделан multipart.
           WARNING: при multipart необходимо самому оформлять все части,
           иначе корректного письма не получится. То есть: части разделять
           "--[boundary]", перед которой пустая строка, а после которой
           rfc-заголовок (который может быть и пустым), потом пустая строка
           и текст. То же нужно сделать в самом начале темплейта. В конце
           надо поставить "--[boundary]--".
В случае [Reason]==TooManyHops доступны еще переменные Hops и MaxHops.

       Внешние чекеры.

Если вам не хватает параметров send, no-send, twit, no-twit, itwit,
chaddr и т.п., и хочется чего-то большего, вы можете это сделать сами,
написав свою программку, определяющую, надо ли слать письмо и
подменяющую адреса. Для этого не обязательно уметь программировать
на C или Pascal - вы можете написать ее на каком-нибудь интерпретируемом
языке (Basic, MultiEdit, Rexx,...) и запускать интерпретатор. Конечно,
это будет дольше, но время критично далеко не всегда, особенно, если
это использовать только для netmail. Для OS/2-версии это функция REXX,
и ее выполнение достаточно эффективно, и задержек практически не
происходит.
Программа подключается параметрами rel2fido-chk или fido2rel-chk. У
этих строк такие параметры:
rel2fido-chk <mask> [<cmdline>]
fido2rel-chk <mask> [<cmdline>]
В командной строке понимаются макросы %from, %to, %size, %area. Для
rel2fido еще есть макрос %attname - имя приаттаченного файла, если
такой есть.

Под UNIX или OS/2, если гейт собран с опцией configure --with-perl
(для OS/2 - был использован makefile.perlos2), чекеры являются
функциями perl. Имя файла задается дополнительными параметрами
rel2fido-chk-pl и fido2rel-chk-pl в gate.conf, а cmdline - имя
вызываемой функции из этого файла. Адреса передаются не макросами
%from, %to, %size, %area, %attname, а предопределенными переменными
$from, $to, $size, $area, $attname. Кроме того, есть переменные $subject и
$body, для fido2rel - $attr и $extsetname (его можно менять), для rel2fido -
$intsetname (его можно менять, но он влияет только на клудж CHRS при
put-chrs=yes, но не влияет на перекодировку). Коды завершения функции
обозначают то же, что и в остальных случаях (см. ниже), только вместо
вывода измененных значений в stdout достаточно изменить значение
предопределенных переменных. Файлы rel2fido.pl и fido2rel.pl - это
примеры таких фильтров, возможные соответствующие строки gate.conf такие:
rel2fido-chk-pl=[home]/rel2fido.pl
fido2rel-chk-pl=[home]/fido2rel.pl
rel2fido-chk echo checkecho
rel2fido-chk * checknetmail
fido2rel-chk all setcharset

Возможные коды завершения:
  0 - default для stdout
  1 - default
  2 - всегда слать, используя stdout
  3 - всегда слать то, что есть
  4 - в /dev/null (все уже сделано)
  5 - отлуп (только для netmail)
  6 - hold для stdout (только для rel2fido netmail)
  7 - hold (только для rel2fido netmail)
Возможные значения <mask>:
  All, Any   - всегда (netmail & echomail)
  Echo       - только для echomail
  <wildcard> - проверяется только для netmail, относится к адресу to.

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

Например,

rel2fido-chk *.ua
rel2fido-chk * /usr/fnet/rechk %from %to %size
fido2rel-chk echo /usr/fnet/fchk %from %to %size %area

Чекеры выводят первой строкой адрес (или список адресов) to, второй,
возможно, адрес from, и третьей, возможно, скорректированный список
конференций либо "netmail", если они кодом завершения сказали использовать
свой stdout. Это дает возможность использовать их вместо chaddr.

Все адреса и area передаются в rfc-формате (т.е. как в Internet).
Для netmail вместо %area подставляется "NetMail".

       Организация ftn-линка via uucp.

Если у вас и на еще каком-нибудь узле есть доступ к internet, то при
помощи LuckyGate вы можете организовать линк с этим узлом. Для этого
существует несколько способов:

1. Двойное гейтование.
   Этот способ позволяет обмениваться только netmail-ом в случае, если на
другом узле также установлен какой-либо гейт. Организовать такой линк очень
просто: достаточно в gate.conf (или в файле, включаемом туда по include)
написать строку, скажем,
route-to fidonet.carrier.kiev.ua 2:463/*
В этом случае все письма на 2:463/* (не имеющие атрибутов hold, direct,
crash, immadiate и пр.) будут гейтоваться. Причем, скажем, письмо на
Pavel Gulchouck 2:463/68 отправится по адресу
Pavel_Gulchouck@f68.n463.z2.fidonet.carrier.kiev.ua, т.е. домен после
зоны напишется указанный в команде route-to. Если в этом домене встречается
символ '@', то все предыдущие '@' заменятся на '%', например, при указании
route-to fidonet.org@carrier.kiev.ua 2:463/*
то же письмо отправится на
Pavel_Gulchouck%f68.n463.z2.fidonet.org@carrier.kiev.ua
Этим следует пользоваться осторожно, т.к. в uupc by ache версий до 6.14
такая форма адресации обрабатывается ошибочно и если у вас в файле
conf\hostpath написано, скажем,
*.fidonet.org fidonet
то такое письмо все равно улетит на fidonet, а не на carrier. Чтобы этого
избежать, надо в файл hostpath добавить строку типа
*.n463.z2.fidonet.org carrier
(если carrier - ваш основной аплинк). Но это тоже несколько опасно для
случая, если, скажем, узел carrier (аплинк) отдает весь *.fidonet.org
вам, т.к. возможен пинг-понг. Поэтому правила роутинга необходимо
согласовать с постмастером вашего узла.
При гейтовании писем по команде route-to не происходит изменение адреса
по chaddr, не действуют ограничения на no-send, binary и twit, длинные
строки не разбиваются.
Команда to-ifmail очень похожа на команду route-to с той разницей, что
гейтуемые письма приобретают наиболее приемлимый для ifmail формат, а
именно:
 - @via не преобразуется в received, а остается полем X-FTN-Via;
 - rrq и cfm не преобразуются в return-receipt-to, а добавляется поле
   X-FTN-Flags, куда пишутся все флаги письма;
 - пробелы в именах сисопов заменяются не на '_', а на '.'.
Команду to-ifmail следует использовать вместо route-to в случае, если
на гейте, с которым вы делаете линк, стоит ifmail.
   Проследите за правильным указанием маршрутизации для ftn-мейлера, т.е.
чтобы почта не улетала по обычному роутингу и чтобы мейлер не пытался
сам прозвониться на другой узел.
   Если узел, с которым вы хотите обмениваться почтой по этой технологии,
не пишет зону, а возможно, и сеть, в доменный адрес при перекодировке
ftn-адресов в internet, то вам необходимо сделать трансляцию доменов,
типа
chdomain .fido.vista.odessa.ua .n467.z2.fidonet.org
тогда адреса приходящих писем типа SysOp@p3.f15.fido.vista.odessa.ua
перед обработкой будут заменяться на SysOp@p3.f15.n467.z2.fidonet.org
и в последствии нормально преобразовываться в первоначальный фидошный
адрес (2:467/15.3). Аналогично, при отправке писем через этот гейт вы
можете написать
route-to fidonet.org 2:467/*
в результате письма в 467/* будут гейтоваться и адрес преобразовываться
сначала в SysOp@p3.f15.n467.z2.fidonet.org, а потом по chdomain в
SysOp@p3.f15.fido.vista.odessa.ua.
Из всех правил роутинга route-to, to-ifmail, no-route действует
последнее подходящее.

2. Uucode.
   В этом случае все почтовые и остальные аттачи на узел, с которым у вас
линк, отправляются обычной почтой в uucode. Для этого вам необходимо
завести локального пользователя вашей почтовой системы (uupc), скажем,
fnet, попросить удаленного сисопа сделать то же и написать в gate.conf
примерно следующее:
route-uue fnet@gul.kiev.ua 2:463/68
filebox=fnet
где 2:463/68 - узел, с которым вы делаете линк,
fnet - ваш локальный пользователь,
fnet@gul.kiev.ua - пользователь на удаленном узле.
Если вы используете не arcmail attach и не binkley style, то вам
необходимо каким-то образом все аттачи на этот узел складывать в
отдельный каталог и написать следующее:
route-uue fnet@gul.kiev.ua 2:463/68 /usr/fnet/out/2/463/68
где /usr/fnet/out/2/463/68 - каталог, куда складываются все аттачи для 2:463/68.
Для binkley style достаточно вместо параметра pktin указать параметр
binkoutbound.

   Вот полное описание формата и ключей route-uue:

route-uue [/base64] [/pgp] [/split=<size>] [/password=<passwd>] [/sign] [/confirm[=t1,t2]] <internet-address> <ftn-address> [<path>]

<path> - файлбокс. Все файлы из этого каталога будут отправляться по
        данному адресу.
/base64, /mime - слать файл в base64;
/pgp  - слать файл pgp encrypted (для этого pgp должен быть инсталлирован
        с обеих сторон, и должен быть известен public pgp key той стороны).
        В этом случае ставится "Content-Transfer-Encoding: x-pgp".
/sign - сделать pgp-сигнатуру (pgp должен быть установлен). При этом
        будет требоваться pgp-сигнатура при приеме файлов от этого линка,
        т.е. этот ключ должен быть установлен с обеих сторон. Сигнатура
        пишется полем заголовка "X-PGP-Sig:" (многострочным).
/password - указать пароль на линк. Этот же пароль будет проверяться
        при приеме файлов от этого линка, т.е. он должен быть прописан
        с обеих сторон. Пароль совершенно не нужен, если используется
        ключ /sign, т.к. pgp обеспечивает гораздо большую степень защиты.
        Пароль регистрозависим, максимальная длина 32 символа. Пишется
        открытым текстом в поле заголовка X-Password каждой части.
/split - разбивать большие файлы на части размером не более <size> килобайт.
        Файл будет автоматически собираться из частей на приеме, если
        там используется attuucp или любой другой софт, понимающий
        Content-Type: message/partial.
/confirm - сохранить отправляемое письмо в каталоге sentdir и запросить
        подтверждение приема файла ("X-Confirm-To:"). Письма будут
        удалены после получения подтверждения, либо отправлены заново
        в случае получения сообщения об ошибке (например, crc error).
        При отсутствии подтверждения файл будет отправляться через
        интервалы t1 в течение t2. Интервалы задаются в формате
        NNh или NNd, например, "/confirm=12h,3d" - отправлять каждые
        12 часов в течение трех суток, если нет подтверждения.
        Если интервалы не указаны, используются предыдущие. Если
        вообще не указаны, используется умолчание 12h,3d. Для того,
        чтобы это работало, удаленный софт должен поддерживать этот
        формат запросов/подтверждений (пока это только LuckyGate 6.01+),
        иначе каждый файл будет отправляться несколько раз (дупы).

        Формат запроса: в заголовке должно быть поле
        X-Confirm-To: user@domain
        где user@domain - адрес, куда отправить подтверждение.
        Использование угловых и круглых скобок не допускается (пока?).

        Формат подтверждения: в заголовке письма должно быть поле
        X-Confirm-Status: (OK|FAIL) <msgid> (comment)
        msgid - message-id или, для multipart, part id в угловых скобках.
        OK означает успешную распаковку всего файла (а не успешное
        получение письма). Comment - произвольный комментарий
        (причина fail, дата приема etc.). Например,
        X-Confirm-Status: OK <12-234-asd@lucky.net> (unsecure)
        X-Confirm-Status: FAIL <21-432-asd@lucky.net> (can't decode pgp)


   Ключи /pgp и /sign могут применяться как вместе, так и по отдельности,
потому что выполняют разные задачи.

   Если не указано ни /mime, ни /pgp, используется uuencode, в этом
случае ставится "Content-Transfer-Encoding: x-uuencode".

   Файлаттач считается секьюрным, если он пришел от известного адреса
(описанного в одной из команд route-uue) и содержит указанные в этой
строке аттрибуты секьюрити: пароль либо pgp-сигнатуру. Такие файлаттачи
складываются в каталог pktout для последующего тоссинга. Несекьюрные
аттачи (от неизвестных адресов, а также с отсутствующим или неправильным
паролем или pgp-сигнатурой, если что-то из этого нужно) складываются в
каталог unsecure, если он указан, либо пересылаются постмастеру, если
не указан. Письма, не содержащие файлаттачей (например, сообщения роботов
о невозможности доставки), пересылаются постмастеру.

   Всем этим занимается утилита attuucp, поэтому вам необходимо
вставить ее вызов в начале (для отправки аттачей) и в конце (для
обработки пришедших пакетов) файла uupc.bat (для UNIX ее нужно
запускать по cron и прописать в /etc/aliases).

   Проследите за тем, чтобы весь netmail для этого узла паковался в
почтовые пакеты, чтобы на них не ставились аттрибуты hold, direct, crash
и пр., либо (что imho хуже) нужно поставить параметр norm-only=no.
При обмене файлэхами с узлом, на котором нет LuckyGate, лучше сами файлы
паковать в один большой zic, тогда у них сохранится дата и время
создания. При обмене LuckyGate-LuckyGate, он сам позаботится об этом.
Также надо быть аккуратным с отправкой больших архивов - на некоторых
узлах максимальный размер письма ограничен до 300K. В этом случае вам
следует попросить своего постмастера увеличить его мегабайт до пяти
(смотря какие архивы вы планируете передавать), либо использовать
ключ /split, если на той стороне тоже LuckyGate.

   FTN-аттачи, отправленные LuckyGate'ом, можно отличить от обычных
писем по наличию поля заголовка "X-FTNattach-Version:" (в данный
момент там ставится "1.0"). В поле "Content-Type:" ставятся параметры
"crc32=" и "name=". Поле "Subject:" формируется по следующему
принципу:
Subject: 12345678.su0, 2/3; 22.08.99 10:52:06
или, если разбиения на части нет, просто
Subject: 12345678.su0; 02.11.98 10:52:06
Дата и время - это время модификации (mtime) отправляемого файла,
локальное для отправителя.

   Если в файле uupc\conf\passwd описать юзера примерно так:
fnet::::"FidoNet Daemon":c:\lgate:c:\lgate\attuucp.exe -l<
то есть последним параметром (shell) указать "attuucp.exe -l<", то приходящие
на этот адрес письма будут обрабатываться на этапе uuxqt (для этого версия
UUPC не должна быть младше 6.14h). В этом случае можно не добавлять запуск
attuucp.exe в конце uupc.bat (но в начале все равно надо добавить).

   Для sendmail в файле aliases можно прописать
fnet: "| /usr/fnet/attuucp -l"

   Если один файл нужно отправить нескольким линкам, он будет отправлен
одним запуском sendmail, если для этих линков прописан одинаковый
метод кодирования, не используется pgp encrypting, не нужно запрашивать
подтверждение, и либо все понимают разбиение на части, либо всем файл
можно отправить одним куском.

   Во время работы attuucp по отправке файлов нельзя параллельно запускать
allfix - в этом случае возможна потеря файлов.

3. Uucp.
   Отправка файловых аттачей на удаленный узел при помощи uucp.
!Предупреждение! это очень опасный способ, не используйте его, если вы не
вполне понимаете, что происходит и если вы не пользовались командой uucp!
Это почти то же самое, что и передача архивов в uucode, с той разницей,
что передача идет по uucp. Для того, чтобы передавать архивы таким
образом, вам следует написать в gate.conf, например,
route-files carrier!luckyua!~ 2:463/*
т.е. адрес заменяется на полный uucp-путь к системе. Вам файлы будут
приходить в каталог uucppublic, откуда вам надо при нулевом коде
завершения uucico (чтобы быть уверенным, что все файлы полностью
приняты) их переместить в ваш inbound-каталог для тоссинга.
Замечания:
1. Вам необходимо убедиться, что на всех узлах по пути команда uucp
поддерживает транзит и для вас разрешена (что обычно не так).
2. Вам необходимо убедиться, что утилита uucp.exe существует и корректно
работает с ключем -C. В версиях uupc до 6.14 она не работает.
3. Вам необходимо быть уверенным, что не возникнет ситуации, когда
пересылается два файла с одинаковыми именами в промежуток, когда
принимающая система не успела принять первый из них. Это могут быть два
почтовых пакета *.??9, либо случай, когда у вашего
абонента неделю нет связи со своим узлом, либо еще что-нибудь. В этом
случае второй из пакетов просто будет потерян.

Внимание! При передаче файлов в uucode или через uucp нельзя параллельно
с работой attuucp запускать эхопроцессор, склонный к удалению
оторванных файлов в outbound-е (например, gecho). Потому что attuucp
сначала удаляет аттачи, а потом уже сами файлы, и некоторое время
файлы смотрятся как оторванные. Для fastecho и прочих распространенных
эхопроцессоров это не страшно, потому что на это время выставляются
флаги занятости этих станций.


       Некоторые технические данные.
       
   При гейтовании из интернета большие письма разбиваются на части,
русская 'Н' заменяется на латинскую 'H'. Аттрибуты RRQ и CFM гейтуются
в обе стороны (за исключением длинного интернетовского адреса). При
повторном прохождении письма через гейт (relcom->fido->relcom или
fido->relcom->fido) оно (почти) не меняется: сохраняются исходные
MsgId, via (received), pid (x-mailer) и другие клуджи (поля заголовка),
причем поля гейтуются не "в лоб" (@PID -> X-FTN-PID и 
Received -> @RFC-Received), а в наиболее близкие по смыслу
(@PID -> X-Mailer, Received -> @Via с изменением порядка на обратный и т.п.),
что делает гейтованое письмо более читаемым и понятным в другой сети
и дает возможность последующего нормального гейтования в другие самые
разнообразне сети.
Делались попытки достичь совместимости в этом отношении с uu2 и ifmail,
а также с fsc. Остановился на некотором компромиссном варианте.

   Имя uucp-системы в UUPC/Ache не может быть длиннее семи символов.
Поэтому если в конфигах UUPC оно длиннее, в конфиге LuckyGate (параметр
fidosystem) нужно оставить только первые семь символов имени этой
системы.

   В случае ошибки при гейтовании личного письма из fido в relcom, оно
(файл *.msg) переименовывается в *.bad (или перекладывается в badmail,
если он указан), и если письмо не прошло через гейт из-за какого-то
ограничения, то автору посылается письмо с указанием этой причины.
Копия этого письма отправляется сисопу на гейте в соответствии с
заданным темплейтом. Если же гейтование не удалось из-за какой-либо
локальной ошибки (например, переполнен диск), то сообщение об этой ошибке
выдается на экран и записывается в файл протокола.
   При ошибке гейтования эхоконференций из fido в relcom, весь pkt-файл
переименовывается в *.bad и причина пишется на экран и в лог-файл.
   При невозможности гейтования личного письма из relcom в fido, оно
переправляется на постмастера гейта и возвращается автору в соответствии
с заданными templates.
   При ошибке гейтования конференции из relcom в fido, весь почтовый
ящик или cnews-пакет переименовывается в *.bad, либо (если письмо
корректно, но такой конференции не существует либо письмо личное),
оно переписывается в badmail.pst. Личные письма могут пересылаться
постмастеру, если указано resend-bad=yes.

		ПРЕДУПРЕЖДЕНИЕ:
		
   Эта версия - не более, чем бета. Распространяется "as is", вы
можете использовать ее на свой страх и риск. За порчу и потерю
информации автор ответственности не несет. Все претензии и флейм
переправляются в /dev/null. Bug reports, пожелания и предложения с
благодарностью принимаются. Особенно благодарен буду при получении
mailbox-а, cnews-пакета или d- и x-файлов, которые gate отрабатывает
некорректно, лучше вместе с его конфигом. Хвалебные отзывы принимаются
только в виде пива. ;-)

   		ОГРАНИЧЕНИЯ:

   Максимальная длина названия конференции - 80 символов.
   Максимальная вложенность файлов конфигурации (include) - 5.
   Максимальная вложенность @if в темплейтах - 16.
   Максимальное количество переменных (@set) в темплейтах - 64.

   Гейт работает только с UUPC by Andrey Chernov ver 5.x, 6.x, 7.x,
с UUPC/Ext by Kendra, sendmail/2 ver 2.02, sendmail 8.x; Тестировался
с версиями UUPC/Ache от 5.09gamma до 7.02, UUPC/Ext 1.12l и 1.12r и
sendmail.
   Из-за ошибки в rmail.exe гейт не работает с UUPC/Ext 1.12p - ее нужно
заапгрейдить до 1.12r или более поздней.
   Из-за ошибки в rnews.exe гейт не работает с Changi старше 0.5.

                КОHТАКТЫ:

   Меня можно найти по адресам Pavel Gulchouck 2:463/68 или
gul@gul.kiev.ua, а также в эхе LUCKY.GATE.
   Конференция lucky.gate доступна по nntp на сервере news.lucky.net.
   Сам LuckyGate распространяется по файлэхе LUCKY.GATE и по списку
рассылки в internet. Кроме того, последняя версия всегда доступна на
ftp://happy.kiev.ua/pub/fidosoft/gate/lgate/*. Текущую версию исходников
можно получить командой "cvs -d :pserver:lgate@happy.kiev.ua:/cvs co lgate".
   Пожалуйста, если кто-нибудь выкладывает LuckyGate на свой ftp, сообщите
об этом, чтобы сделать официальный mirror. Тогда я смогу давать на него
ссылки и сообщать об изменении URL, если такое случится.

   				Lucky carrier,
   						Павел Гульчук.