<attila.bruncsak@...> wrote:

> Please see the attached patch which removes this bug.

Got it.

--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

Hello,

I got some strange syslog messages like:

skipping greylist because (from=<sender@...>, rcpt=(nil),
addr=...

After a short investigation I found
that in some case the whystr string variable
does not get a valid string assignment
and left with the original empty string value.

Please see the attached patch which removes this bug.

Bests,
Attila

On Thu, Dec 17, 2009 at 04:24:22PM +0300, Vladimir Vassiliev wrote:
> I commented out first of them but it did not help.
> Is this possible to use very handy spf statements with postfix &
milter-greylist?

AFAIK there is no way to get our local IP in Postfix. A workaround could
be to use 127.0.0.1 if it cannot be read. Feel free to submit a patch...

--
Emmanuel Dreyfus
manu@...

It works for me too, thanks.

--
Vladimir Vassiliev <vova@...>

On Thu, Dec 17, 2009 at 04:24:22PM +0300, Vladimir Vassiliev wrote:
>
> I just migrated from sendmail to postfix and now I have some problems
> with milter-greylist.  I recompiled milter-greylist (ver 4.1.3) with
> USE_POSTFIX and now it complains on start: "spf self clause is broken
> on Postfix"

Because of the spf self clause, you cannot use USE_POSTFIX and spf
directives in your greylist.conf.  That's something I don't really
understand so I patch it away.

		 Petar Bogdanovic

--- spf.c.orig  2008-09-29 20:52:42.000000000 +0200
+++ spf.c       2008-09-29 20:53:12.000000000 +0200
@@ -493,10 +493,6 @@
         acl_data_t *ad;
         void *data;
  {
-#ifdef USE_POSTFIX
-       mg_log(LOG_ERR, "spf self clause is broken on Postfix");
-       exit(EX_DATAERR);
-#endif
         ad->spf_status = *(enum spf_status *)data;
         return;
  }

Hi,

I just migrated from sendmail to postfix and now I have some problems with
milter-greylist.
I recompiled milter-greylist (ver 4.1.3) with USE_POSTFIX and now it complains
on start:
"spf self clause is broken on Postfix"

I have such lines in config:
racl greylist spf self
racl whitelist spf pass

I commented out first of them but it did not help.
Is this possible to use very handy spf statements with postfix &
milter-greylist?


--
Vladimir Vassiliev <vova@...>

<attila.bruncsak@...> wrote:

> Even better looking, if you go to the mailing list web archive:

Right, I missed it because it was lot in HTML stuff, which my MUA does
not render.

--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

Hi,

On Fri, Dec 11, 2009 at 04:19:25PM +0100, manu@... wrote:
> <attila.bruncsak@...> wrote:
>
> > I wanted to make the delay for the hard stop to be customizable,
> > so please include the patch attached, may be useful for others.
>
> yahoo now strips attachements. We really need to move somewhere else!

I can provide a mailman managed mailinglist if you really want to move
the list.
It's quite comfortable .
There are already about a dozen lists running there, one more doesn't hurt.


--
Ralf 'Snake' Gebhart

manu@... wrote:

> yahoo now strips attachements. We really need to move somewhere else!

It is possible that the owner of the group can configure the
list to allow attachments.

If you visit the home page for the group, you will see that
there is a category for "Attachments."  Also one for "Files."

http://tech.groups.yahoo.com/group/milter-greylist/?yguid=1849176

When configured to accept attachments, the attachments go into
the attachments area and a link is placed at the bottom of the
message in question.

I'm not saying that there aren't better mailing list managers;
I'm just trying to point out that while the group is on Yahoo,
there may be a way to set it up to be more satisfactory.

					 Marty

> > I wanted to make the delay for the hard stop to be customizable,
> > so please include the patch attached, may be useful for others.
>
> yahoo now strips attachements. We really need to move somewhere else!
>
> Please send it to manu@... directly.
>

Yahoogroups does strip it, but it is replacing the attachment with a
URI.
Using this you should still be able to retrieve the attachment(s).

Even better looking, if you go to the mailing list web archive:

http://tech.groups.yahoo.com/group/milter-greylist/message/5392

I think it is quiet fair to do, no possible size limit problem
on the e-mail receiving end.

Bests,
Attila

<attila.bruncsak@...> wrote:

> I wanted to make the delay for the hard stop to be customizable,
> so please include the patch attached, may be useful for others.

yahoo now strips attachements. We really need to move somewhere else!

Please send it to manu@... directly.

--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

Hello,

When I stop the mg with "/etc/init.d/milter-greylist stop" command
on my Centos system I never got clean greylist.db dump.
There is always greylist.db-XXXXXX temporary file left over,
and the actual dump is from a previous dump event.

It looks like that the mg requires on my system (actually quiet
performant)
more than the default 3 seconds to finish writing the dump.
(The killproc sends shortly after the TERM signal a KILL
signal to the process)

I wanted to make the delay for the hard stop to be customizable,
so please include the patch attached, may be useful for others.

I changed the default value of the delay to be 5 seconds,
but this can be changed as specifying different value
for the hardstopdelay variable in the /etc/sysconfig/milter-greylist
file.

Bests,
Attila

<attila.bruncsak@...> wrote:

> There is no surprise here, I am not running "make install" at all.
> I am just copying the new milter-greylist binary through our firewall
> from the internal development system to the external production
> mail perimeter system.

Right, that explains everything. Feel free to contribute the code that
create the dump directory before dropping root privileges.

--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

> > Was there any incompatible changes which I am not aware of?
> > Or it should just work as before and there is a bug on that
> platform?
>
>
> A quick fix for you would be to configure --sysconfdir=/etc
> --localstatedir=/var
>
> Here is the long story:
>
> The previous configure script forced --sysconfdir=/etc
> --localstatedir=/var

Thanks for the detailed information,
I will add this to my site specific configure script.

>
> This oddity has been "fixed", with the result of a bare configure
> producing a milter-greylist that look in /usr/local/etc/mail and
> /usr/local/var/milter-greylist.
>
> There is a backward compatibility check for a config file in
> /etc, hence
> the rough warning you get. The same test was forgotten for the dump
> file, which should not be a problem, as loosing the database
> just cause
> extra delay.

Would be great to add the checking code.
The result is more than a simple extra delay,
milter-greylist is exiting with EX_OSERR.

>
> What is really surprising here is that make install did not create
> /usr/local/var/milter-greylist (the install-db rule should do it).
>
> What does make install produces at yours?
>

There is no surprise here, I am not running "make install" at all.
I am just copying the new milter-greylist binary through our firewall
from the internal development system to the external production
mail perimeter system.

Bests,
Attila

> There was some discussion a while back about moving the
> configuration
> to "support normal user 'make install'" (search for this subject in
> the archives).
>
> So the 'legacy configuration' notice should just be a warning.
>
> As for the mkstemp issue, you should just be able to make those dirs
> and go.

Thanks the info.
But I will rather try to change the config parameters
to match the current production directories.

>
> btw, what were your config parameters?
>

My site specific configure script is the following, and I am running it
as a non privileged user:

#! /usr/bin/ksh
CFLAGS="" ./configure --with-libmilter=/usr/local/src/sendmail/libmilter
make

Bests,
Attila

<attila.bruncsak@...> wrote:

> Was there any incompatible changes which I am not aware of?
> Or it should just work as before and there is a bug on that platform?


A quick fix for you would be to configure --sysconfdir=/etc
--localstatedir=/var

Here is the long story:

The previous configure script forced --sysconfdir=/etc
--localstatedir=/var

This oddity has been "fixed", with the result of a bare configure
producing a milter-greylist that look in /usr/local/etc/mail and
/usr/local/var/milter-greylist.

There is a backward compatibility check for a config file in /etc, hence
the rough warning you get. The same test was forgotten for the dump
file, which should not be a problem, as loosing the database just cause
extra delay.

What is really surprising here is that make install did not create
/usr/local/var/milter-greylist (the install-db rule should do it).

What does make install produces at yours?

--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

Attila,

There was some discussion a while back about moving the configuration
to "support normal user 'make install'" (search for this subject in
the archives).

So the 'legacy configuration' notice should just be a warning.

As for the mkstemp issue, you should just be able to make those dirs
and go.

btw, what were your config parameters?

Bill

Bill Levering
idbill@...
KFP: 0C38 4D7E 5B50 94FE 992D  406D 6C81 DE33 5459 A1AC




On Dec 10, 2009, at 2:21 AM, <attila.bruncsak@...> wrote:

> Hello,
>
> I have recently tried to upgrade mg from version 4.3.2 to 4.3.4 on
> Tru64
> UNIX.
> I used the same configuration options and make as with the previous
> version.
>
> Now I got the following warning at the end of the configure stage:
>
> config.status: WARNING:  'Makefile.in' seems to ignore the --
> datarootdir
> setting
>
> At startup time of the new binary I got the following message:
>
> legacy configuration file '/etc/mail/greylist.conf' is used instead of
> '/usr/local/etc/mail/greylist.conf'. IT SHOULD BE RENAMED!
>
> I got as well the following error soon after startup and the mg exits:
>
> milter-greylist:
> mkstemp("/usr/local/var/milter-greylist/greylist.db-HlnPA0pY") failed:
> No such file or directory
>
> Was there any incompatible changes which I am not aware of?
> Or it should just work as before and there is a bug on that platform?
>
> Bests,
> Attila
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Hello,

I have recently tried to upgrade mg from version 4.3.2 to 4.3.4 on Tru64
UNIX.
I used the same configuration options and make as with the previous
version.

Now I got the following warning at the end of the configure stage:

config.status: WARNING:  'Makefile.in' seems to ignore the --datarootdir
setting

At startup time of the new binary I got the following message:

legacy configuration file '/etc/mail/greylist.conf' is used instead of
'/usr/local/etc/mail/greylist.conf'. IT SHOULD BE RENAMED!

I got as well the following error soon after startup and the mg exits:

milter-greylist:
mkstemp("/usr/local/var/milter-greylist/greylist.db-HlnPA0pY") failed:
No such file or directory

Was there any incompatible changes which I am not aware of?
Or it should just work as before and there is a bug on that platform?

Bests,
Attila

I never did figure out the following... but I did figure out the root
of my problem.

spam-milter.sock != spamd.sock

Bill


Bill Levering
idbill@...
KFP: 0C38 4D7E 5B50 94FE 992D  406D 6C81 DE33 5459 A1AC




On Nov 8, 2009, at 9:11 PM, Bill Levering wrote:

> WHat does this mean?
>
> Nov  9 05:10:04 syreen milter-greylist: greylist: mi_stop=1
> Nov  9 05:10:04 syreen milter-greylist: smfi_main() returned 0
>
> Nov  9 05:10:04 syreen sm-mta[31086]: nA95A41n031086: Milter
> (greylist): read returned -1: Connection reset by
> 159.139.11-93.rev.gaoland.net
> Nov  9 05:10:04 syreen sm-mta[31086]: nA95A41n031086: Milter
> (greylist): to error state
> Nov  9 05:10:04 syreen sm-mta[31086]: nA95A41n031086: Milter
> (greylist): init failed to open
> Nov  9 05:10:04 syreen sm-mta[31086]: nA95A41n031086: Milter
> (greylist): to error state
> Nov  9 05:10:10 syreen sm-mta[31068]: nA959kRx031068: Milter
> (greylist): write(D) returned -1, expected 23: Broken pipe
> Nov  9 05:10:10 syreen sm-mta[31068]: nA959kRx031068: Milter
> (greylist): to error state
>
>
> Bill Levering
> idbill@...
> KFP: 0C38 4D7E 5B50 94FE 992D  406D 6C81 DE33 5459 A1AC
>
>
>
>

WHat does this mean?

Nov  9 05:10:04 syreen milter-greylist: greylist: mi_stop=1
Nov  9 05:10:04 syreen milter-greylist: smfi_main() returned 0

Nov  9 05:10:04 syreen sm-mta[31086]: nA95A41n031086: Milter
(greylist): read returned -1: Connection reset by
159.139.11-93.rev.gaoland.net
Nov  9 05:10:04 syreen sm-mta[31086]: nA95A41n031086: Milter
(greylist): to error state
Nov  9 05:10:04 syreen sm-mta[31086]: nA95A41n031086: Milter
(greylist): init failed to open
Nov  9 05:10:04 syreen sm-mta[31086]: nA95A41n031086: Milter
(greylist): to error state
Nov  9 05:10:10 syreen sm-mta[31068]: nA959kRx031068: Milter
(greylist): write(D) returned -1, expected 23: Broken pipe
Nov  9 05:10:10 syreen sm-mta[31068]: nA959kRx031068: Milter
(greylist): to error state


Bill Levering
idbill@...
KFP: 0C38 4D7E 5B50 94FE 992D  406D 6C81 DE33 5459 A1AC

New issue...

Nov  8 19:42:54 syreen milter-greylist: spamd connect failed:
Permission denied
Nov  8 19:42:54 syreen milter-greylist: ACL evaluation failure

At first, I thought this was a spamd issue, but I've tweaked
permissions on the bayes, whitelist, socket... etc.
That and spamd works fine  with the spam-milter... I turned on verbose
logging and spamd isn't complaining about anything unusual (missing
vuserinfo/valias/vpop).

So I'm back to trying to find out why milter-greylist is having a
problem.


I turned on milter-greylist verbose loggings... and still no new info.

Debian 5.0.3
Milter-greylist 4.2.3
SpamAssassin Server version 3.2.5
    running on Perl 5.10.0
    with zlib support (Compress::Zlib 2.012)

sendmail running as root :(
root     23248  0.0  0.6  66168  3148 ?        Ss   20:17   0:00
sendmail: MTA: accepting connections

spamd running as:
root     20421  0.1 10.2 116204 53760 ?        Ss   19:37   0:05 /usr/
sbin/spamd --create-prefs --max-children 5 --helper-home-dir -u spam -
d --pidfile=/var/run/spamd.pid -v

greylist runnings as:
greylist 21933  0.0  0.5 116940  2760 ?        Ssl  19:59   0:01 /usr/
local/bin/milter-greylist -w 8m -P /var/run/greylist.pid -u greylist -
p /var/run/milter-greylist/milter-greylist.sock

milter config entry for spamd:
spamdsock unix "/var/run/spamass/spamass.sock"
dacl blacklist spamd > 10 msg "Your message is considered spam"


If I set the perms on spamd.sock from:
root@syreen:/usr/local/src/milter-greylist-4.2.3 > ls -l /var/run/
spamass/
total 4
-rw-r--r-- 1 spamass-milter nogroup 5 Oct 28 17:58 spamass.pid
srw------- 1 root           root    0 Oct 28 17:58 spamass.sock


to:
root@syreen:/usr/local/src/milter-greylist-4.2.3 > ls -l /var/run/
spamass/
total 4
-rw-r--r-- 1 spamass-milter nogroup 5 Oct 28 17:58 spamass.pid
srw-rw-rw- 1 root           root    0 Oct 28 17:58 spamass.sock


I now get:
Nov  8 20:05:47 syreen milter-greylist: spamd read failed: Connection
reset by peer

(I have an almost identical setup on CentOS 4.8, which works.
(Sendmail/greylist run as smmsp & spamd runs as spamd) )

Bill

PS. Have I mentioned that Debian appears to be lacking in sendmail
support? (missing files, etc)

Bill Levering
idbill@...
KFP: 0C38 4D7E 5B50 94FE 992D  406D 6C81 DE33 5459 A1AC

New issue...

Nov  8 19:42:54 syreen milter-greylist: spamd connect failed:
Permission denied
Nov  8 19:42:54 syreen milter-greylist: ACL evaluation failure

At first, I thought this was a spamd issue, but I've tweaked
permissions on the bayes, whitelist, socket... etc.
That and spamd works fine  with the spam-milter... I turned on verbose
logging and spamd isn't complaining about anything.

So I'm back to trying to find out why milter-greylist is having a
problem.


I turned on milter-greylist verbose loggings... and still no new info.


Bill

Bill Levering
idbill@...
KFP: 0C38 4D7E 5B50 94FE 992D  406D 6C81 DE33 5459 A1AC

On 11/5/09 5:33 AM, manu@... wrote:
>
> If you want to use DKIM, you will have to whitelist the sender's domain
> at RCPT stage ACL:
>
> racl whitelist from /@foo\.com$/
> dacl whitelist from /@foo\.com$/ dkim pass
> dacl blacklist from /@foo\.com$/ msg "foo.com must use DKIM"

Yes, I thought of doing that for Gmail/googlemail. In my opinion, that's
a more elegant way of accepting mail for Gmail's multiple "floating"
relays. Greylisted mails tends to be resent by another (or several
other) IPs. (Of course, if you already use lazyaw its usually not a
problem).

But maintaining a list for others that use DKIM is too much manual
labour for being worth it, at least for my taste.

Re,
/P

I uploaded a patch to improve the dacl handling and fix the dkim bug. The patch
('mg-4.3.5_to_mg-4.3.5-dacl.patch') can be found here:

http://tech.groups.yahoo.com/group/milter-greylist/files/

(Sorry, Yahoo does not allow direct links). The file patches against the latest
CVS check-out.

The modification will base the precedence of racl and dacl lines on the order in
which they appear in the conf file.

As an example, a conf file like

dacl whitelist dkim pass
racl greylist default

will whitelist a sender if it passes dkim, and default to greylisting if not.

The modifications to the code turned out to be quite simple; all of the
necessary hooks were already in there. The logic as the message passes through
the milter stages is as follows:

1. The connecting host and sender are processed in the rcpt stage of the SMTP
connection and checked for matches against racl statements

2. If a racl matches, the milter checks to see if there are any dacl statements
before the matching racl statement. If so, the result of the racl match is
stored and the message proceeds to the data and body stage of the SMPT
connection.

If there are no dacl statements before the matching racl line, no data stage
processing is needed and the racl result is processed immediately in the rcpt
stage (saving CPU).

3. If there are dacl lines before the matching racl line, the milter will
continue to the data and body stages of the SMPT connection. It will process the
dacl commands up to the matching racl line. In case of a match, the dacl result
will be processed; no match means the racl results will be restored.

Although the processing logic may sound complicated, the result is very
intuitive and greatly increases performance by not passing messages through the
dacl stage when not needed.

Take this example:

racl whitelist spf pass
dacl whitelist dkim pass
racl greylist default

If a sender matches the spf clause, the message is accepted immediately and does
not pass through the data stage.

The line based dacl precedence will also work for black listing based on content
scanning:

racl whitelist spf
dacl whitelist dkim pass
dacl blacklist spamd
racl greylist default

In this case, all messages that match spf or dkim will be whitelisted, whereas
any other messages which are flagged by Spamassasin will be rejected. All other
messages will be greylisted.

Please go ahead and try the patch. I am very interested to hear your feedback.
By turning on 'verbose' in the conf file, the program will clearly log its
racl/dacl decisions. The logic should become quite obvious after a couple of
messages.

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the milter-greylist
group.

   File        : /mg-4.3.5_to_mg-4.3.5-dacl.patch
   Uploaded by : reschauzier <reschauzier@...>
   Description : Improve handling of data stage commands

You can access this file at the URL:
http://groups.yahoo.com/group/milter-greylist/files/mg-4.3.5_to_mg-4.3.5-dacl.pa\
tch

To learn more about file sharing for your group, please visit:
http://help.yahoo.com/l/us/yahoo/groups/original/general.htmlfiles

Regards,

reschauzier <reschauzier@...>

In the course of testing a modification to improve the handling of dacl
statements, I noticed the strangest thing. It looks like there is a bug in
dkimcheck.c that will prevent dkim from working.

Note this piece of code from the function dkimcheck_error():

   106 	 break;
   107  }
   108
   109  if (priv->priv_dkim != DKIM_STAT_OK) {
   110 	 (void)dkim_free(priv->priv_dkim);
   111 	 priv->priv_dkim = NULL;
   112  }
   113
   114  return retval;
   115 }

Line 109 checks the pointer priv->priv_dkim against an integer value. Since
DKIM_STAT_OK equals 0, every time the pointer is not NULL, it will be reset.
This is exactly what happens as a message goes through the SMTP stages in
milter-greylist. As a result, no message is ever checked for dkim.

The correct code should be:

   109  if (priv->priv_dkimstat != DKIM_STAT_OK) {

With this change the dkim checking seems to work properly.

Does this really mean no-one was ever able to run a successful DKIM check? Or am
I overlooking something?

reschauzier <reschauzier@...> wrote:

> The milter does not work, on the other hand, for message authentication
> systems such as DomainKeys and DKIM. reason is that the dacl can
> override a racl whitelist, but not a racl greylist or blacklist.

Of course: if a RCPT stage ACL reject the message for all recipients,
there is no DATA stage ACL.

If you want to use DKIM, you will have to whitelist the sender's domain
at RCPT stage ACL:

racl whitelist from /@foo\.com$/
dacl whitelist from /@foo\.com$/ dkim pass
dacl blacklist from /@foo\.com$/ msg "foo.com must use DKIM"

Of course it you do that with multiple domains, a list will be usefull.
Or even better, a DNSRBL of domains using DKIM.

--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

Thanks for the info. It confirms what I found: the current milter-greylist will
work for spam and virus filtering (albeit with a significant performance hit, as
you mention).

The milter does not work, on the other hand, for message authentication systems
such as DomainKeys and DKIM.

The reason is that the dacl can override a racl whitelist, but not a racl
greylist or blacklist.

A simple conf file like

racl greylist default
dacl whitelist dkim pass

will not function as expected (allow all dkim authenticated messages, greylist
all others), as will an even simpler file like

dacl whitelist dkim pass

The racl will greylist by default, and a dacl whitelist will not override a racl
greylist (if it sounds confusing, that's because it is; it took me couple of
hours sorting through the source to figure this out)

Is there anyone that can prove me wrong and has a working DKIM/DK setup with
milter-greylist?

Thanks,
Rudy.


--- In milter-greylist@yahoogroups.com, chasd <chasd@...> wrote:
>
> > For my interest, what have you been using the dacls for?
> > Interfacing w/ spamd, DKIM check or something else?
>
> To see if applying virus or spam filtering would be worthwhile at
> that mail processing point.
> I hadn't realized that one of the reasons the delivery times
> increased so much was because _every_ message was being processed. It
> makes sense now. The performance issue was why I didn't move forward
> toward implementation, I just did testing. With finer-grained control
> of dacl processing, I'd revisit my tests.
>
>
> --
> Charles Dostale
> System Admin - Silver Oaks Communications
> http://www.silveroaks.com/
> 824 17th Street, Moline  IL  61265
>

> For my interest, what have you been using the dacls for?
> Interfacing w/ spamd, DKIM check or something else?

To see if applying virus or spam filtering would be worthwhile at
that mail processing point.
I hadn't realized that one of the reasons the delivery times
increased so much was because _every_ message was being processed. It
makes sense now. The performance issue was why I didn't move forward
toward implementation, I just did testing. With finer-grained control
of dacl processing, I'd revisit my tests.


--
Charles Dostale
System Admin - Silver Oaks Communications
http://www.silveroaks.com/
824 17th Street, Moline  IL  61265

On Tue, Nov 03, 2009 at 12:56:15PM -0000, reschauzier wrote:
> For my interest, what have you been using the dacls for? Interfacing w/ spamd,
DKIM check or something else?

I use it as a cheap content filter, using the base64 encoded win32
executable header.

--
Emmanuel Dreyfus
manu@...