| Опция -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 |