amavisd-milter-users Mailing List for amavisd-milter

amavisd-milter-users — User discussions

This list is closed, nobody may subscribe to it.

2005	Jan	Feb	Mar	Apr	May (1)	Jun (3)	Jul (9)	Aug (7)	Sep (2)	Oct	Nov (4)	Dec
2006	Jan (12)	Feb	Mar (10)	Apr (10)	May (15)	Jun	Jul (11)	Aug	Sep	Oct (25)	Nov (3)	Dec (31)
2007	Jan (15)	Feb (5)	Mar (3)	Apr (10)	May	Jun	Jul (5)	Aug (2)	Sep (25)	Oct	Nov	Dec
2008	Jan (7)	Feb (4)	Mar	Apr	May	Jun	Jul (4)	Aug	Sep	Oct (8)	Nov	Dec (5)
2009	Jan	Feb	Mar	Apr	May (1)	Jun (20)	Jul (14)	Aug (7)	Sep	Oct (14)	Nov	Dec
2010	Jan (6)	Feb	Mar (1)	Apr	May (2)	Jun (1)	Jul	Aug	Sep (12)	Oct (1)	Nov (9)	Dec
2011	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov (1)	Dec
2013	Jan (4)	Feb	Mar	Apr	May (1)	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2015	Jan	Feb	Mar	Apr	May (1)	Jun	Jul	Aug	Sep	Oct	Nov	Dec (1)
2016	Jan	Feb	Mar	Apr (1)	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2017	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec (1)
2018	Jan	Feb	Mar (1)	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2019	Jan (3)	Feb	Mar	Apr (1)	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2020	Jan	Feb	Mar	Apr (1)	May (1)	Jun	Jul	Aug	Sep	Oct	Nov	Dec

Flat | Threaded

1 2 3 .. 14 > >> (Page 1 of 14)

Re: ALL_TRUSTED for nearly all messages

From: Matus U. - f. <uh...@fa...> - 2020-05-11 12:30:22

On 20.04.20 19:56, Matus UHLAR - fantomas wrote:
>I use amavisd-milter on Debian machines with amavis 2.10 and 2.11
>
>I recently found out that nearly all messages hit ALL_TRUSTED Now, on 
>one server I see 79 mails without ALL_TRUSTED and 9700 without.
>
>messages received via LMTP don't have this probem.
>
>it seems that this problem is amavisd-new dependent, since Debian 10 with
>amavisd-milter 1.5.0 and amavisd-new 2.11.0 does have that problem, but
>Debian 8 with amavisd-milter 1.5.0 and amavisd-new 2.10.1 does not.
>
>however, the solution probably can lie in amavisd-milter, or at least
>amavisd-milter may be suspect so I post here

FYI: It's bug in amavisd-new documented here:

https://gitlab.com/amavis/amavis/-/issues/61

patched amavisd-new works properly

-- 
Matus UHLAR - fantomas, uh...@fa... ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Windows found: (R)emove, (E)rase, (D)elete

ALL_TRUSTED for nearly all messages

From: Matus U. - f. <uh...@fa...> - 2020-04-20 17:56:37

Hello,

I use amavisd-milter on Debian machines with amavis 2.10 and 2.11

I recently found out that nearly all messages hit ALL_TRUSTED 
Now, on one server I see 79 mails without ALL_TRUSTED and 9700 without.

messages received via LMTP don't have this probem.

it seems that this problem is amavisd-new dependent, since Debian 10 with
amavisd-milter 1.5.0 and amavisd-new 2.11.0 does have that problem, but
Debian 8 with amavisd-milter 1.5.0 and amavisd-new 2.10.1 does not.

however, the solution probably can lie in amavisd-milter, or at least
amavisd-milter may be suspect so I post here


-- 
Matus UHLAR - fantomas, uh...@fa... ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"One World. One Web. One Program." - Microsoft promotional advertisement
"Ein Volk, ein Reich, ein Fuhrer!" - Adolf Hitler

Re: amavisd-milter has been moved to GitHub

From: Matus U. - f. <uh...@fa...> - 2019-04-16 10:43:46

On 17.01.19 00:01, Petr Řehoř wrote:
>amavisd-milter has been moved to https://github.com/prehor/amavisd-milter

by the way, it would be nice if the SF page could link to github:
http://amavisd-milter.sourceforge.net/

this page still shows as first in web searches
-- 
Matus UHLAR - fantomas, uh...@fa... ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Quantum mechanics: The dreams stuff is made of.

amavisd-milter has been moved to GitHub

From: Petr Ř. <pr...@gm...> - 2019-01-16 23:02:16

amavisd-milter has been moved to https://github.com/prehor/amavisd-milter

P.

Re: fork after initializing milter socket

From: Matus U. - f. <uh...@fa...> - 2019-01-04 16:15:38

On 04.01.19 15:29, Matus UHLAR - fantomas wrote:
>amavisd-milter 1.6.1 does daemonize, and opens milter socket after that,
>exiting if it returns error
>
>We want to change the socket permissions after daemon is started, and this
>order of commands makes it problematic, e.g. debian bug 854180
>(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854180)
>
>the daemon() should be called after calling smfi_opensocket().
>
>This would also make possible to return error in case of impossibility to create
>socket, so the caller knows it failed.

this patch moves the daemonising section after opening socket.
I have tried with amavisd-milter 1.6.1 and 1.5.0, works nicely.

you can find it at test.fantomas.sk/amavisd-milter-main.c.patch

--- main.c.orig	2013-04-22 02:36:12.000000000 +0200
+++ main.c	2019-01-04 15:35:29.486854008 +0100
@@ -379,17 +379,6 @@
 	}
     }
 
-    /* Run in the background */
-    if (daemonize) {
-	if (daemon(1, 1) != -1) {
-	    daemonized = 1;
-	} else {
-	    logmsg(LOG_ERR, "could not fork daemon process: %s",
-		strerror(errno));
-	    exit(EX_OSERR);
-	}
-    }
-
     /* Connect to milter socket */
 #ifdef HAVE_SMFI_SETBACKLOG
     if (mlfi_socket_backlog > 0) {
@@ -406,6 +395,17 @@
     }
 #endif
 
+    /* Run in the background */
+    if (daemonize) {
+	if (daemon(1, 1) != -1) {
+	    daemonized = 1;
+	} else {
+	    logmsg(LOG_ERR, "could not fork daemon process: %s",
+		strerror(errno));
+	    exit(EX_OSERR);
+	}
+    }
+
     /* Greetings message */
     logmsg(LOG_WARNING, "starting %s %s on socket %s", progname, VERSION,
 	mlfi_socket);

-- 
Matus UHLAR - fantomas, uh...@fa... ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
If Barbie is so popular, why do you have to buy her friends?

fork after initializing milter socket

From: Matus U. - f. <uh...@fa...> - 2019-01-04 14:45:07

Hello,

amavisd-milter 1.6.1 does daemonize, and opens milter socket after that,
exiting if it returns error

We want to change the socket permissions after daemon is started, and this
order of commands makes it problematic, e.g. debian bug 854180
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854180)

the daemon() should be called after calling smfi_opensocket().

This would also make possible to return error in case of impossibility to create
socket, so the caller knows it failed.

-- 
Matus UHLAR - fantomas, uh...@fa... ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Atheism is a non-prophet organization.

Re: Use {client_name} if available instead of hostname passed to xxfi_connect

From: Florian P. <blu...@xi...> - 2018-03-04 03:13:12

Attachments: signature.asc

On 16.12.2017 00:16, Florian Pritz via amavisd-milter-users wrote:
> Spamassassin's RDNS_NONE check tests if the rdns field in the Received header
> is empty or "unknown". Postfix sets the client_name macro to "unknown" when the
> FcrDNS check fails, but the hostname passed to xxfi_connect is set to the IP
> address which means that RDNS_NONE will never trigger. Fix this by using
> client_name if available and only fall back to the hostname parameter
> otherwise.

Is anybody still reading this ML? I'd love to get this merged.

Florian

Use {client_name} if available instead of hostname passed to xxfi_connect

From: Florian P. <blu...@xi...> - 2017-12-15 23:35:26

Attachments: signature.asc

Spamassassin's RDNS_NONE check tests if the rdns field in the Received header
is empty or "unknown". Postfix sets the client_name macro to "unknown" when the
FcrDNS check fails, but the hostname passed to xxfi_connect is set to the IP
address which means that RDNS_NONE will never trigger. Fix this by using
client_name if available and only fall back to the hostname parameter
otherwise.

diff -ur src/amavisd-milter-1.6.1/amavisd-milter/mlfi.c src-mod/amavisd-milter-1.6.1/amavisd-milter/mlfi.c
--- src/amavisd-milter-1.6.1/amavisd-milter/mlfi.c	2015-05-24 20:59:19.000000000 +0200
+++ src-mod/amavisd-milter-1.6.1/amavisd-milter/mlfi.c	2017-12-15 18:08:15.007525175 +0100
@@ -315,6 +315,7 @@
     const void *addr;
     const char *prefix;
     const char *daemon_name;
+    const char *client_host;
     int		len, plen;
 
     logmsg(LOG_DEBUG, "%s: CONNECT", hostname);
@@ -331,8 +332,20 @@
     (void) memset(mlfi, '\0', sizeof(*mlfi));
     mlfi->mlfi_amasd = -1;
 
+	/* Try to get client_name from macros */
+	if ((client_host = smfi_getsymval(ctx, "{client_name}")) != NULL) {
+	    logqidmsg(mlfi, LOG_INFO, "client_name: %s", client_host);
+	    if ((mlfi->mlfi_client_host = strdup(client_host)) == NULL) {
+		logqidmsg(mlfi, LOG_ERR, "could not allocate memory");
+		mlfi_setreply_tempfail(ctx);
+		return SMFIS_TEMPFAIL;
+	    }
+	} else {
+		logqidmsg(mlfi, LOG_INFO, "{client_name} undefined at connect time! Falling back to libmilter value.");
+	}
+
     /* Save connection informations */
-    if (hostname != NULL && *hostname != '\0') {
+    if (hostname != NULL && *hostname != '\0' && mlfi->mlfi_client_host == NULL) {
 	if ((mlfi->mlfi_client_host = strdup(hostname)) == NULL) {
 	    logmsg(LOG_ERR, "%s: could not allocate memory", hostname);
 	    mlfi_setreply_tempfail(ctx);

The provided package in Debian/Ubuntu , is too old

From: Hamy <per...@ya...> - 2016-04-16 10:04:24

Hi, Even though the latest release is 1.6.1 , released in 2015, the latest provided Debian/Ubuntu package, is 1.5.0 which is for 2010.
I am not quite sure how the package updating procedure should take place but It's been suggested that i contact the developers. could you please take a look at this?
Thanks
https://launchpad.net/ubuntu/+source/amavisd-milter

https://packages.debian.org/source/sid/amavisd-milter

SMTP_AUTH from sendmail to Amavisd-new using Amavisd-Milter.

From: jan h. p. <jh...@jh...> - 2015-12-10 00:03:14

Hi everyone,

I have a Centos 6 server with sendmail. On this server I use
Milter-Greylist in combination with Amavisd-new and Amavisd-milter. This
works fine except for one thing.
When users authenticate to sendmail using smtp_auth (saslauthd) milter
greylist sees this perfectly and skips all greylisting, but amavisd-new
doesn't seem to receive the SMTP_AUTH policy bank through the
amavisd-milter. I have added the following lines to amavisd-new to make
the policy_bank available:

$policy_bank{'SMTP_AUTH'} = {
  protocol => 'AM.PDP',
  originating => 1,
  bypass_banned_checks_maps => [1],
  bypass_spam_checks_maps => [1],
  os_fingerprint_method => undef,
  spam_lovers_maps => [1],
  banned_files_lovers_maps => [1],
};

In sendmail.mc I have the following lines to support milter-greylist and
amavisd-milter.

define('MILTER', `1')
INPUT_MAIL_FILTER(`greylist',`S=local:/var/lib/milter-greylist/milter-greylist.sock')
define(`confMILTER_MACROS_CONNECT', `j, {if_addr}')
define(`confMILTER_MACROS_HELO', `{verify}, {cert_subject}')
define(`confMILTER_MACROS_ENVFROM', `r, b, i, {auth_authen}')
define(`confMILTER_LOG_LEVEL',`10')
define(`confMILTER_MACROS_ENVRCPT', `{greylist}')
INPUT_MAIL_FILTER(`milter-amavis',
`S=local:/var/spool/amavisd/amavisd-milter.sock, F=T, T=S:10m;R:10m;E:10m')
TRUST_AUTH_MECH(`PLAIN GSSAPI KERBEROS_V4 DIGEST-MD5 CRAM-MD5 LOGIN')
DAEMON_OPTIONS(`port=smtp,Name=MTA,Family=inet6,InputMailFilters=greylist;milter-amavis')
DAEMON_OPTIONS(`port=smtps,Name=TLSMTA,Family=inet6,InputMailFilters=greylist;milter-amavis,M=s')

I start amavisd-milter with the following options:

/usr/sbin/amavisd-milter -p /var/run/amavisd/milter.pid -w
/var/spool/amavisd -s local:/var/spool/amavisd/amavisd-milter.sock -S
/var/spool/amavisd/amavisd.sock -m 50 -B -d 3

A few questions:

Does anyone have a working config, or maybe some pointers to where I
need to look to get this fixed?

Everything like virus scanning and spamscanning etc works just fine. The
only problem I have is that I want to skip spam scanning when someone
authenticates using SMTP_AUTH.

The version of Amavisd-milter is 1.6.1.

Thanks,
Jan Hugo Prins

ANNOUNCE: amavisd-milter-1.6.1

From: Petr R. <pr...@gm...> - 2015-05-24 22:18:39

Bug and compatibility fixies:
- Fixed bug when creating amavisd-new policy bank names.

P.

ANNOUNCE: amavisd-milter-1.6.0

From: Petr R. <pr...@gm...> - 2013-05-19 21:42:01

New features:
- Added new amavisd-milter option -B which pases value of
  {daemon_name} milter macro as amavisd-new policy bank name.

Bug and compatibility fixies:
- Added amavisd-milter.spec for compilation with rpmbuild.
- Fixed typo which prevents using LDFLAGS on Debian.
- Fixed missing definition of true and false in libmilter/mfapi.h.

P.

Re: postfix mail filtering with amavisd-milter - works!

From: Simon H. <li...@th...> - 2013-01-31 16:05:17

Jo Rhett wrote:
>First, I found that all of the published recipes for spam containment with postfix are bogus.
> They either create back-scatter, or they drop messages which hit the filter instead of rejecting them
> in the SMTP session like they are supposed to. So if something is a false positive, the far side will never
> know it happened.

Yep, nearly all the howtos etc use after-queue scanning.

>So I've done some testing and work, and I currently have postfix using amavisd-milter as a before-queue
> spam test, which properly rejects spam during the SMTP session. This solves both of the previous
> problems and brings postfix users closer to being a proper mail gateway. I believe very strongly that this
> recipe should replace the existing documentation, to avoid sending new users out to become backscatters.

Yes, it works very nicely. I've been running this setup for a couple of years now. It was made a lot easier when the amavisd-milterpackage appeared in Debian. I agree the setup could do with being made more prominent.
The main downside, as the various docs that discuss it mention, is that you can end up needing significant processing capability to deal with peak influx of email.

I've also added Policyd (aka Cluebringer), http://www.policyd.org, which rather nicely handles per-SASL-login quotas/throttling of outbound traffic (we provide the servers for customers to use as a relay as well). Just last wekk we shoved a customer on that sends bulk mails out to several thousand people at a time, and several times a week - it was nice to see Policyd just throttling them down to a sane message rate rather than swamping the system as happened on the older box I run.

>I'm still working out a few details: namely, how to get the permissions right on the amavisd-milter socket. As soon as that is sorted I'll provide documentation. 
>Hint: there's no mystery here. I installed amavisd-milter as documented and pointed postfix at it :-)

I can't remember now if I had to modify anything, but in the init script in Debian I see it has :
 if [ "$MILTERSOCKETTYPE" = "pipe" ]; then
  if [ "$MILTERSOCKETOWNER" ]; then
   chown "$MILTERSOCKETOWNER" "$MILTERSOCKET"
  fi
  if [ "$MILTERSOCKETMODE" ]; then
   chmod "$MILTERSOCKETMODE" "$MILTERSOCKET"
  fi
 fi

And in /etc/default/amavisd-milter it has :
# Set these two options if you want the socket to have
# special permissions (usefull mainly for postfix).
MILTERSOCKETOWNER="postfix:postfix"
MILTERSOCKETMODE="0660"

I set this up initially under Debian Squeeze, it's now running Wheezy.

Re: postfix mail filtering with amavisd-milter - works!

From: Simon H. <li...@th...> - 2013-01-31 10:24:14

Jo Rhett wrote:
>First, I found that all of the published recipes for spam containment with postfix are bogus.
> They either create back-scatter, or they drop messages which hit the filter instead of rejecting them
> in the SMTP session like they are supposed to. So if something is a false positive, the far side will never
> know it happened.

Yep, nearly all the howtos etc use after-queue scanning.

>So I've done some testing and work, and I currently have postfix using amavisd-milter as a before-queue
> spam test, which properly rejects spam during the SMTP session. This solves both of the previous
> problems and brings postfix users closer to being a proper mail gateway. I believe very strongly that this
> recipe should replace the existing documentation, to avoid sending new users out to become backscatters.

Yes, it works very nicely. I've been running this setup for a couple of years now. It was made a lot easier when the amavisd-milterpackage appeared in Debian. I agree the setup could do with being made more prominent.
The main downside, as the various docs that discuss it mention, is that you can end up needing significant processing capability to deal with peak influx of email.

I've also added Policyd (aka Cluebringer), http://www.policyd.org, which rather nicely handles per-SASL-login quotas/throttling of outbound traffic (we provide the servers for customers to use as a relay as well). Just last wekk we shoved a customer on that sends bulk mails out to several thousand people at a time, and several times a week - it was nice to see Policyd just throttling them down to a sane message rate rather than swamping the system as happened on the older box I run.

>I'm still working out a few details: namely, how to get the permissions right on the amavisd-milter socket. As soon as that is sorted I'll provide documentation. 
>Hint: there's no mystery here. I installed amavisd-milter as documented and pointed postfix at it :-)

I can't remember now if I had to modify anything, but in the init script in Debian I see it has :
 if [ "$MILTERSOCKETTYPE" = "pipe" ]; then
  if [ "$MILTERSOCKETOWNER" ]; then
   chown "$MILTERSOCKETOWNER" "$MILTERSOCKET"
  fi
  if [ "$MILTERSOCKETMODE" ]; then
   chmod "$MILTERSOCKETMODE" "$MILTERSOCKET"
  fi
 fi

And in /etc/default/amavisd-milter it has :
# Set these two options if you want the socket to have
# special permissions (usefull mainly for postfix).
MILTERSOCKETOWNER="postfix:postfix"
MILTERSOCKETMODE="0660"

I set this up initially under Debian Squeeze, it's now running Wheezy.

postfix mail filtering with amavisd-milter - works!

From: Jo R. <jr...@ne...> - 2013-01-31 06:05:02

So I've been a sendmail admin for 20+ years and never saw any need for postfix. I was very happy with sendmail and amavisd-milter and amavisd. However, when rebuilding my colo box I decided to go ahead and learn postfix, just so I can see how the other half lives ;-)

First, I found that all of the published recipes for spam containment with postfix are bogus. They either create back-scatter, or they drop messages which hit the filter instead of rejecting them in the SMTP session like they are supposed to. So if something is a false positive, the far side will never know it happened. Neither of these situations is playing fair to other parties.

So I've done some testing and work, and I currently have postfix using amavisd-milter as a before-queue spam test, which properly rejects spam during the SMTP session. This solves both of the previous problems and brings postfix users closer to being a proper mail gateway. I believe very strongly that this recipe should replace the existing documentation, to avoid sending new users out to become backscatters.

I'm still working out a few details: namely, how to get the permissions right on the amavisd-milter socket. As soon as that is sorted I'll provide documentation. 
Hint: there's no mystery here. I installed amavisd-milter as documented and pointed postfix at it :-)

-- 
Jo Rhett
Net Consonance : net philanthropy to improve open source and internet projects.

spec file for RPM builds

From: Jo R. <jr...@ne...> - 2013-01-21 00:15:55

Attachments: amavisd-milter.spec

Petr, if you were to include this spec file in the tarfile, RHEL and variants would be able to build RPMs of your software like so:
	rpmbuild -tb amavisd-milter-1.5.0.tar.gz

I'm willing to send you patches for new versions, but the likely only change will be to change the version string at the top unless you change the command line options.

amavisd.sock - No such file or directory

From: Cristian S. <cs...@ik...> - 2011-11-16 11:05:55

Hi,

I'm having trouble configuring amavisd-milter-1.5.0, Postfix 2.6.6 and 
amavisd-new 2.7.0. Amavisd-milter can't open socket to Amavisd even 
though the socket file exists and permissions should be ok. The error 
message is

   yyy.fi: grab amavisd connection 1
   yyy.fi: could not connect to amavisd socket 
unix:/var/amavis/tmp/amavisd.sock: No such file or directory
   yyy.fi: set reply 451 4.6.0 Content scanner malfunction

I'm using Amavisd-milter command line:

su - amavis -s /bin/sh -c "amavisd-milter -w /var/amavis/tmp
   -m 2 -M 540 -p /var/amavis/var/amavisd-milter.pid
   -s inet:10029@localhost
   -S unix:/var/amavis/tmp/amavisd.sock -d9 -f"

Clips from amavisd.conf:
  $MYHOME = '/var/amavis';
  $TEMPBASE = "$MYHOME/tmp";
  $ENV{TMPDIR} = $TEMPBASE;
  $unix_socketname = "$TEMPBASE/amavisd.sock";
  $interface_policy{'SOCK'} = 'AM.PDP-SOCK';
  $policy_bank{'AM.PDP-SOCK'} = {
   protocol => 'AM.PDP',
   auth_required_release => 0,
};


Permission tree:
  drwxr-x--- 6 root amavis 4096 Sep 23 16:08 /var/amavis/
  drwxr-x--- 2 amavis amavis 4096 Nov 15 14:59 /var/amavis/tmp/
  srwxr-x--- 1 amavis amavis 0 Nov 15 13:16 amavisd.sock

I also tried to debug manually:
  - created an email in /var/amavis/tmp/xyz123/email.txt
  - su -s /bin/bash amavis
  - socat - UNIX-CONNECT:/var/amavis/tmp/amavisd.sock

   request=AM.PDP
   sender=<ro...@yy...>
   recipient=<cri...@xx...>
   protocol_name=ESMTP
   client_address=127.0.0.1
   tempdir=/var/amavis/tmp/xyz123

   version_server=2
   log_id=19796
   setreply=250 2.5.0 Ok,%20id=19796,%20continue%20delivery
   insheader=0 X-Virus-Scanned amavisd-new%20at%20xxx.yyy.fi
   return_value=continue
   exit_code=0

Can anyone explain, what's the problem? Why Amavisd-milter can't connect 
to Amavisd socket even though socket seems to work fine manually.

Platform is CentOS 6.0, SELinux is switched off.

Thanks in advance, Best Regards,

-- 
Cristian Seres