Le 29/12/2010 00:48, Mark Martinec a écrit :
> Clay,
>
>> Given the number of pre-releases, do you have any rough idea concerning
>> the 2.7.0 stable release? I have a few boxes in need of an update to
>> 2.6.4, but may hold until 2.7.0 depending on release timing.
>> Any thoughts?
> The main reason that 2.7.0-pre12 is not named 2.7.0-rc1 is that
> I would still like to provide a cleaner and more general purpose
> API/syntax of incorporating SQL and LDAP lookups directly and
> explicitly into @*_maps lists of lookup tables, instead of the
> current implicit inclusion of SQL and LDAP into each @*_maps list.
> Also the amavisd-signer would need a cleaner way of being supplied
> with its configuration, and preferably supporting a PKCS11 API
> to access crypto devices for DKIM-signing mail (which I have
> half-finished) - although this could perhaps wait for the 2.7.1.
>
> Both of these might require some less-then-perfect incompatible
> measure, which would be less appropriate for some later
> minor-version update - the 2.7.0 would be a perfect corner
> stone to complete this transition.
>
> Whatever changes are happening lately between -pre* releases
> are some new features for which I have an immediate need or
> for which I see a good opportunity, or some optimizations,
> cleaning and some minor bug fixes.
>
> As far as functional stability and bug-free operation is
> concerned, I'd say that 2.7.0-pre12 is as good (if not better)
> that 2.6.4.  So if one does not mind dealing with a potential
> compatibility change (to implement the first item above) which
> might still be pending, there is no reason not to go for
> 2.7.0-pre12, especially with new installations or with major
> upgrades/overhaul of the whole mail system. The compatibility
> concerns are clearly documented in release notes, the most
> intrusive of which is perhaps a need for a couple of new
> fields in an SQL database if using it (penpals & SQL logging)
> and possibly a change in data types of some SQL fields.
>
>   Mark
>
> ------------------------------------------------------------------------------
> Learn how Oracle Real Application Clusters (RAC) One Node allows customers
> to consolidate database storage, standardize their database environment, and, 
> should the need arise, upgrade to a full multi-node Oracle RAC database 
> without downtime or disruption
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> AMaViS-user mailing list
> AMaViS-user@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/amavis-user 
>  Please visit http://www.ijs.si/software/amavisd/ regularly
>  For administrativa requests please send email to rainer at openantivirus dot 
> org
Hi Mark
i think I have a problem with forward method into policy bank.
I use this kind of settings to forwarding to the right smtp after amavisd

remote postfix client => amavisd port 10019 => remote postfix server 10025

i've many smtp talking to amavisd, so each one use a different port
(10019 in this example)
So I need to redirect email to the right smtp after amavisd

$interface_policy{'10019'} = 'ORIGINATING-SMTP06';

$policy_bank{'ORIGINATING-SMTP06'} = {  # mail supposedly originating
from our users
  originating => 1,
  virus_admin_maps => ['r...@mx2.eole-its.com'],
  spam_admin_maps  => ['r...@mx2.eole-its.com'],
  warnbadhsender   => 0,
  notify_method  => 'smtp:[aa.aa.aa.aa]:10029',
  forward_method => 'smtp:[aa.aa.aa.aa]:10025',  # set to undef with milter!
  smtpd_discard_ehlo_keywords => ['8BITMIME'],
  bypass_header_checks_maps => [1],
  terminate_dsn_on_notify_success => 0,  # don't remove NOTIFY=SUCCESS
option
};


of course default forward method is not the same:
$notify_method  = 'smtp:[bb.bb.bb.bb]:10029';
$forward_method = 'smtp:[bb.bb.bb.bb]:10025';  # set to undef with milter!


with amavisd 2.7.0pre12, forward use always default forward method even
when policy bank is called.
(I can see ORIGINATING-SMTP06 policy called into logs, but FWD log is
always the default one (bb.bb.bb.bb in this example)
 FWD from <t...@test.test> -> <to...@starbridge.org>,BODY=7BIT 250 2.0.0
from MTA(smtp:[bb.bb.bb.bb]:10025): 250 2.0.0 Ok: queued as 00C5024C003

It should be aa.aa.aa.aa, it was ok into amavisd 2.6.4

I hope my explanation is clear, my english is poor, sorry for this long
text !


regards
Tonio


------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and, 
should the need arise, upgrade to a full multi-node Oracle RAC database 
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
AMaViS-user mailing list
AMaViS-user@lists.sourceforge.net 
https://lists.sourceforge.net/lists/listinfo/amavis-user 
 Please visit http://www.ijs.si/software/amavisd/ regularly
 For administrativa requests please send email to rainer at openantivirus dot 
org

Reply via email to