[AMaViS-user] amavisd-new-2.4.4 pre-release 1 is available

This is a discussion on [AMaViS-user] amavisd-new-2.4.4 pre-release 1 is available within the Amavis User forums, part of the Anti-Spam and Anti-Virus Related Forums category; A pre-release of amavisd-new-2.4.4 is available at: http://www.ijs.si/software/amavisd/a....4-...


Go Back   Usenet Forums > Anti-Spam and Anti-Virus Related Forums > Amavis User

FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #1 (permalink)  
Old 10-27-2006
Mark Martinec
 
Posts: n/a
Default [AMaViS-user] amavisd-new-2.4.4 pre-release 1 is available

A pre-release of amavisd-new-2.4.4 is available at:

http://www.ijs.si/software/amavisd/a....4-pre1.tar.gz

2.4.4 is primarily a maintenanance release over 2.4.3.
Here are the more important entries from RELEASE_NOTES:


COMPATIBILITY WITH 2.4.3

- incompatible change in a AM.PDP/milter setup: header fields are now
prepended at hdridx 1 by default (instead of 0) for compatibility with
signing milters, the value is now configurable. See below for details.


BUG FIXES:

- do_ascii: fix a bug where timer was not restored after decoding of a
textual mail part, so a timeout for subsequent decoding operations
on the same message was limited to 10 seconds (and to 30 seconds
for a call to SpamAssassin), regardless of $child_timeout setting;

- don't call PerlIO::get_layers with Perl 5.8.0, the function was
introduced with 5.8.1; reported by Joel Nimety;

- avoid deep recursion in evaluating a regular expression in header checks
which caused testing for presence of a all-whitespace line in folded
header field very slow for degenerate cases of header; the inefficient
expression was introduced with amavisd-new-2.4.0; reported and a sample
provided by Kai Risku;


OTHER CHANGES:

-limit recursion in MIME::Parser to $MAXFILES to prevent MIME parser from
fully traversing degenerate cases of broken MIME messages which can take
excessive amount of time and memory; reported and a sample provided by
Joshua Goodall, solution suggested by David F. Skoll;

- check for already running daemon at startup time, preventing a user
mistake of trying to start another instance of the daemon without
stopping the currently running process; suggested by Jo Rhett;

[...]

- AM.PDP/milter setup: new configuration setting $prepend_header_fields_hdridx,
also a member of policy banks, with a default value of 1. It is used as an
argument hdridx in an AM.PDP attribute 'insheader' which in a milter setup
is passed on as an argument hdridx to a smfi_insheader call. This is an
incompatible change from 2.4.3, previously a value of 0 was used and was
not configurable. The change (and configurability) is provided for peaceful
coexistence with some other milters like dkim-milter and dk-milter which
also use a value of 1 in their calls to smfi_insheader when prepending
their header fields. The value of $prepend_header_fields_hdridx only
affects AM.PDP protocol and only if $append_header_fields_to_bottom is
false (which is default).

Discussion: when sendmail calls its milters, its Received header field
is not yet created and passed on to milters, yet it is already counted as
one header field for the purpose of smfi_insheader hdridx interpretation.
When a milter wants to prepend its header field(s), specifying hdridx of
0 does prepend its header fields above the yet-to-be-inserted Received
header field as expected, and specifying 1 inserts its header field(s)
just below the yet-to-be-inserted Received header field. If some milters
in a chain specify 0 and others a 1 it affects the final order of inserted
header fields in unexpected ways. It would be natural to always prepend
fields with an index 0, but for signing milters like dk-milter this is
not acceptable, as it would be expected to include a not-yet-created
Received header field in its signature (this is not a problem with
dkim-milter, which can deal with excessive Received headers it encounters
when verifying). For this reason signing milters like dkim-milter and
dk-milter insert their header fields (signature) at index 1, and if
amavisd-milter wants to coexist in such a setup, it must also insert
its header fields at index 1.

The conclusion is: when amavisd (with its helper program) is used in a
milter setup along with other milters, it should use the same hdridx value
as other milters, which in case of signing dkim-milter and dk-milter is 1.
If there are no such milters, either a 1 or a 0 would do, although a value
of 0 produces a more natural order of header fields, matching that of a
post-queue content filtering setup.

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=...057&dat=121642
_______________________________________________
AMaViS-user mailing list
AMaViS-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/...fo/amavis-user
AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3
AMaViS-HowTos:http://www.amavis.org/howto/
Reply With Quote
Reply
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are Off
[IMG] code is Off
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On



All times are GMT +1. The time now is 06:13 AM.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO 3.0.0