Рецепты из ifmail-2.15dev5-al

Здесь Вы можете скачать некоторые выдержки из моей ветки ifmail-2.15dev5-al в виде патчей к оригинальному dev5.
Почему "выдержки"? Потому, что я не преследую цель опубликовать мою ветку, а выкладываю только то, что пользовалось или пользуется спросом и решено в моей ветке.

Опция -DHAS_STDARG_H для сборки с gcc-3.3.x, который не поддерживает varargs.h
Применять в случаях, когда сборка ifmail завершается ошибкой, типа:
In file included from lutil.c:7:
/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.3.1/include/varargs.h:4:2: #error "GCC no longer implements <varargs.h>."
/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.3.1/include/varargs.h:5:2: #error "Revise your code to use <stdarg.h>."
lutil.c:164: error: syntax error before "va_dcl"
lutil.c:165: error: syntax error before '{' token
lutil.c:172: warning: type defaults to `int' in declaration of `va_start'
.....
ifmail-2.15dev5.gcc33x.patch
Опция -DINSERT_ORGANIZATION. При отсутствии Origin в сообщениях из эх в поле Organization вставляется Unknown. Для таких сообщений производится попытка определения адреса отправителя по клуджам MSGID или REPLYTO. Кроме того, с этой опцией в поле Organization будет вставляться Unknown, если текстовая часть Origin (а также ^ARFC-Organization, ^AOrganization или поля Organization в теле письма) состоит только из пробелов и табуляций.
Применять в случаях, если inn отбрасывает статьи с ошибками в логах, типа:
rejected 437 Body of header is all blanks in "Organization" header
ifmail-2.15dev5.origin.patch
Опция -DEDIT_FUTURE_DATES для гейтования FTN пакетов из эхоконференций, у которых дата установлена в будущем дальше, чем одни сутки. Если опция установлена, то в таких датах год будет исправляться на текущий или предыдущий.
Применять в случаях, если inn отбрасывает статьи с ошибками в логах, типа:
Article posted in the future
ifmail-2.15dev5.future.patch
Просто патч, который совмещает в себе опции -DINSERT_ORGANIZATION и -DEDIT_FUTURE_DATES.
ifmail-2.15dev5.origin.future.patch
ifmail 2.15dev5 в результате двойного гейтования срезает RFC-Message-Id (и другие RFC-* клуджи, а также RFC-поля из тела письма) в транзитных письмах, идущих с другого гейта.

При гейтовании писем (из ftn в rfc) с полем From в теле письма (именно такие идут с другого гейта) ifmail вставляет в rfc сообщение поле X-FTN-Sender. При втором гейтовании (уже из rfc в ftn) при наличии поля X-FTN-Sender считается,
что сообщение произошло на ftn (ftnorigin=1). Но письма с X-FTN-Sender явно произошли не в ftn, а на другом гейте.

Такая ошибка происходит потому, что при определении происхождения письма анализируется адрес отправителя на соответствие его фидошной форме записи (p.f.n.z.fidonet.org). Если адрес фидошный, то принимается решение о происхождении письма на ftn. Но при этом в первую очередь анализируется адрес из X-FTN-Sender, и только при отсутствии X-FTN-Sender анализируется адреc из поля From. Однако, в X-FTN-Sender всегда проставляется _фидошный_ адрес гейта, на котором произошло письмо (поле предназначено для хранения адреса гейта). В результате чего письмо ошибочно считается проишедшим на ftn. Хотя письма с From: в теле письма идут с других гейтов, а не с ftn.  Соответственно при гейтовании из rfc в ftn все необходимые rfc поля (From, Message-Id, References и т.д.) не вставляются в соответствующие клуджи ftn писем, т.е.  происходит срезание этих клуджей в транзитных письмах с других гейтов.

Применять в случаях, когда узел на ifmail используется как раздающий почту на другие гейты.
ifmail-2.15dev5-rfcgate.patch
Кроме того. Некоторые ifmail-гейты пользуются nnrpd фильтром для формирования фидошного MSGID. При использовании такого фильтра для писем с гейта необходимо предотвращять вставку в пакеты клуджа RFC-Message-Id. Для транзитных же писем RFC-Message-Id необходимо сохранять.

Для этих целей при втором гейтовании необходимо как-то различать транзитные письма и письма с гейта. Во все письма с гейта фильтр производит вставку поля X-FTN-MSGID с ftn адресом гейта. И этим полем как-раз можно воспользоваться для формирования признака "транзит/не транзит" (f_transit). Используя данный флаг можно удалять и другие rfc-клуджи из писем со своего гейта, для этого в return-ах соответствующих условий (как это сделано для Message-Id) необходимо заменить 1-цы или 2-ки на (f_transit?1:0) или (f_transit?2:0) соответственно. Кроме того, если закомментировать предпоследний return в функции needputrfc и раскомментировать последний, то во все транзитные письма будут вставлены (если в условиях выше не оговорено иное) в виде клуджей все rfc-поля. В общем используя флаг f_transit можно более гибко управлять вставкой/удалением rfc-клуджей в транзитных письмах или письмах с гейта.

Данный патч можно применять и не формируя фильтром фидошный MSGID. Для этого необходимо создать фильтр, добавляющий в письма с гейта не X-FTN-MSGID, а, например, X-IFMAIL-ORIGIN, содержащий как и X-FTN-MSGID адрес гейта. Тогда в патче необходимо заменить X-FTN-MSGID на X-IFMAIL-ORIGIN.

Применять в случаях использования nnrpd фильтра для формирования фидошного MSGID. Можно модернизировать и использовать для более гибкого управления rfc-клуджами в зависимости от того, транзитное письмо или с гейта.
ifmail-2.15dev5-f_transit.patch
filter_nnrpd.pl
Просто патч, который совмещает в себе два предыдущих патча.
ifmail-2.15dev5-rfcgate.f_transit.patch
На linux-2.6 ifmail пакеты тоссит совсем не в том порядке, в каком они запакованы в бандл. На тредах это сразу и не заметно, но бывает, что ответы на письма гейтуются раньше самих писем с вопросами (и на линков оно тоже запаковывается навыворот). Видно на каком-то этапе в системе что-то поменялось и системный readdir() начал отдавать список файлов не в порядке их создания, а в каком-то совершенно другом.

Данный патч добавляет сортировку пакетов по времени при гейтовании.

Применять в случаях нарушения порядка тоссинга пакетов.
ifmail-2.15dev5.sort_ifunpack.patch

PS. Опции задаются в конфиге исходников (CONFIG) ifmail перед компиляцией. И не забудьте добавить опцию -DDO_NEED_TIME ;-)
PPS. ifmail-2.15dev5

e-mail
fido (work): Andrew Leonov 2:4641/500.911
fido (home): Andrew Leonov 2:4641/500.119