Jonathan,

> Using the following options, the messages are being passed,
> but not defanged:
> $final_banned_destiny     = D_PASS;
> $defang_banned = 1;

> Option 1 works well for local hosts.  FYI this document is
> geared to postfix.  I'm using sendmail with amavisd-milter.

AM.PDP protocol does not support modifications to mail body,
which is why defanging with AM.PDP/milter has no effect.
In principle the protocol could be extended to provide it,
but there is not much point transferring message back and
forth across a milter protocol and then again cross AM.PDP
protocol, when doing the same over SMTP already provides the
functionality. 

> The option still works though.  Amavisd-milter must be passing
> the IP to amavis-new. 

It is.

> Option 10, I think, will be more difficult (authenticated non-local
> hosts).  I'm using TLS on ports 25 and 2500, and SSL on ports 465 and
> 4650.  I know milters have the capability of determining whether or not
> someone authenticated because there is Milter Macro for it called
> auth_authen.  Another milter I use, milter-greylist uses this to
> determine if the user authenticated and to not delay them if they have.
>
> Does amavis-new have the capability of picking up on this?  Would it be
> appropriate for it to be able to do so if used in conjunction with
> amavisd-milter?  If so, I could ask the amavisd-milter developers to add
> support for it.

Currently there is no capability to pass additional information from
amavisd-milter to amavisd over AM.PDP, although adding another attribute
to the protocol is quite straightforward. Amavisd could then switch
policy banks based on a value of such new attribute. It should not be
much work on the amavisd side. The code would go to sub check_amcl_policy,
see there for example on how it loads policy bank MYNETS (and/or MYUSERS)
based on passed client IP address (or sender address).

One possibility is to place most of decision making into amavisd-milter,
in which case an attribute/value pair like:  policy_bank=BANKNAME
would do.

Alternatively, amavisd-milter could pass additional bits and pieces of
information to amavisd (like a value of some MTA macro, or info in SASL
authentication), then add code to amavisd to decide if it wants to
load some policy bank based on such information.

  Mark

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
AMaViS-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/amavis-user
AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3
AMaViS-HowTos:http://www.amavis.org/howto/

Reply via email to