Dear list,

Just to tell you that I just submitted a devel version of the port for FreeBSD.
http://www.freebsd.org/cgi/query-pr.cgi?pr=76954

Until the new port is added to the tree, a tarball is available at:
http://www.teaser.fr/~cguibourg/bsd/

Regards.


PS: note that /var/db/milter-greylist is moved to /var/milter-greylist.

----------------------------------------------------------------
Cedric HILLEMBRAND
Administrateur Systèmes et Réseau
Centre d'Etude Spatiale des Rayonnements
CESR UMR 5187 - CNRS - UPS
9, avenue Colonel Roche BP 4346
31028 Toulouse Cedex 4
Tel : 05.61.55.66.62 Fax : 05.61.55.67.01
----------------------------------------------------------------

HILLEMBRAND Cedric wrote:
> Dear list,
>

Hi,

> I’m a new user of Milter-Greylist.
>
> I installed milter-greylist since few days with sendmail 8.12.1 (and
> spamassasin + mitler-spamc, smrazor) on Solaris 8.
>
> The results are really good !
> But I’m disappointed, because after one or two days, my daemon stops to
> work.
> It was the case this night. I can read this information from my syslog :
>
> /Feb  2 03:44:10 castor sendmail[19897]: [ID 801593 mail.info]
> j122i7nG019897: Milter add: header: X-Greylist: Default is to whitelist
> mail, not delayed by milter-greylist-1.7.5 (castor.cesr.fr
> [195.83.102.11]); Wed, 02 Feb 2005 03:44:10 +0100 (MET)
>
> Feb  2 03:44:15 castor sendmail[19909]: [ID 801593 mail.notice] NOQUEUE:
> POSSIBLE ATTACK from [4.32.196.36]: newline in string "narryaz\r "
>
> Feb  2 03:44:20 castor sendmail[19910]: [ID 801593 mail.error]
> j122iInH019910: milter_read(greylist): cmd read returned 0, expecting 5
>
> Feb  2 03:44:20 castor sendmail[19910]: [ID 801593 mail.info]
> j122iInH019910: Milter (greylist): to error state
>
> /I tried to install the new version (1.7.5), but the results are the
> same... where can I look ?

If you're running Solaris 8, make sure you've installed the latest
patches. There is a nasty memory leak in the pthread libraries prior to
patch  108827-40. It makes the milter-greylist process grow pretty
quickly and dump core once the available virtual memory is exhausted.

This patch has later been obsoleted by 108993-39.
So check that you have one of those two patches installed. You can get
the latest 108993 revision from http://sunsolve.sun.com/. Beware, this
is a pretty nasty patch that really requires a quick reboot after
installation, as it screws up user authentification. It's also not
possible to install it using PatchPro (it is marked as making the kernel
instable).

--
Matthieu Herrb

On Mon, Jan 31, 2005 at 10:11:17AM -0600, Thomas Cameron wrote:
> I wonder if it would be possible to automatically whitelist someone to whome
> I sent e-mail.  In other words, if there is a recent message from me to
> jowblow@..., when a response comes in from jowblow@...
> milter-greylist would whitelist it and pass it along without delaying it.

I wonder if this is a good idea. I get lots of virus infected e-mail which
abuse the e-mail address of a friend a sender. If Milter Greylist would
have whitelisted his address because I've sent e-mail to him I would
get those viruses again.

	 Kind regards

--
Matthias Scheler                                  http://scheler.de/~matthias/

Hi

According to this, we'll soon have to find a new idea for filtering spam
efficiently:

http://news.com.com/Experts+Zombie+trick+set+to+send+spam+sky-high/2100-
7349_3-5560664.html?tag=nefd.top

Summary: new spam engines don't send spam directly but rather use ISP
SMTP servers. That will workaround greylisting, as the ISP SMTP server
will retry sending.

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

ello,

I have attached two patches against 1.6 fixing the following issues:

	 * rc-redhat.sh.in: fix startup position; '50' was too early
	   because important services like 'named' will be started later
	   (55). '79' seems to be a good value as sendmail is started at
	   '80'

	 * rc-redhat.sh.in: drop the uid/gid manually. The daemon
	   itself does not change the gid/supplementary groups and
	   would run with too much privilegies therefore.



Enrico

ello,

I attached a patch fixing an issue with libspf (http://www.libspf.org/).
This library does not define FALSE but SPF_FALSE only.



Enrico

>  * rc-redhat.sh.in: drop the uid/gid manually. The daemon
> 	  itself does not change the gid/supplementary groups and
> 	  would run with too much privilegies therefore.

dropping gid/groups in the daemon would be better, but afair this method
is disliked as it is not very portable. Nevertheless, the attached patch
makes exactly this...



Enrico

Hi Matthieu,

Thank's for your help.
I added patch 108993-40 (the patch 108993-39 has been obsoleted by this
one) and I will see...

Best regards.

Cédric.

A 14:26 02/02/2005 +0100, Matthieu Herrb a écrit :
>HILLEMBRAND Cedric wrote:
>>Dear list,
>
>Hi,
>
>>I’m a new user of Milter-Greylist.
>>I installed milter-greylist since few days with sendmail 8.12.1 (and
>>spamassasin + mitler-spamc, smrazor) on Solaris 8.
>>The results are really good !
>>But I’m disappointed, because after one or two days, my daemon stops to
>>work.
>>It was the case this night. I can read this information from my syslog :
>>/Feb  2 03:44:10 castor sendmail[19897]: [ID 801593 mail.info]
>>j122i7nG019897: Milter add: header: X-Greylist: Default is to whitelist
>>mail, not delayed by milter-greylist-1.7.5 (castor.cesr.fr
>>[195.83.102.11]); Wed, 02 Feb 2005 03:44:10 +0100 (MET)
>>Feb  2 03:44:15 castor sendmail[19909]: [ID 801593 mail.notice] NOQUEUE:
>>POSSIBLE ATTACK from [4.32.196.36]: newline in string "narryaz\r "
>>Feb  2 03:44:20 castor sendmail[19910]: [ID 801593 mail.error]
>>j122iInH019910: milter_read(greylist): cmd read returned 0, expecting 5
>>Feb  2 03:44:20 castor sendmail[19910]: [ID 801593 mail.info]
>>j122iInH019910: Milter (greylist): to error state
>>/I tried to install the new version (1.7.5), but the results are the
>>same... where can I look ?
>
>If you're running Solaris 8, make sure you've installed the latest
>patches. There is a nasty memory leak in the pthread libraries prior to
>patch  108827-40. It makes the milter-greylist process grow pretty quickly
>and dump core once the available virtual memory is exhausted.
>
>This patch has later been obsoleted by 108993-39.
>So check that you have one of those two patches installed. You can get the
>latest 108993 revision from http://sunsolve.sun.com/. Beware, this is a
>pretty nasty patch that really requires a quick reboot after installation,
>as it screws up user authentification. It's also not possible to install
>it using PatchPro (it is marked as making the kernel instable).
>
>--
>Matthieu Herrb
>
>
>

On Thu, Feb 03, 2005 at 08:37:16AM +0100, manu@... wrote:
>
http://news.com.com/Experts+Zombie+trick+set+to+send+spam+sky-high/2100-7349_3-5\
560664.html?tag=nefd.top

'"The e-mail infrastructure is beginning to fail," Linford warned. "You'll
see huge delays in e-mail and servers collapsing. It's the beginning of
the e-mail meltdown."'

Great. "Death of Email Predicted, Film at 11"

I don't understand all the doom and gloom surrounding this. Yes, there
may be some bad negative effects in the short-term... greylisting, as
you said, gets less effective, and possibly ISPs get thrown on blacklists
(bad) or they can't be because they're too big (bad in a different way).

But long-term if this is the way things go, I see it as a good thing. ISPs
have a lot more incentive to care about zombie spambot networks than
the average Joe home user with an unpatched Windows box sitting on his
broadband link. And this development means ISPs get a choke-point from
which they can impose maximum sending rates, do monitoring, etc. and
lock those bots out.

And of course the other possibility is that this technique may not work
because of the above, and spammers will go back to doing it the way they
did before, and all of this news will be moot.

Overall I'm not very worried. I certainly don't see it as a "beginning
of the e-mail meltdown" -- that's FUD.

--
Brent J. Nordquist <b-nordquist@...> N0BJN
Other contact information: http://kepler.its.bethel.edu/~bjn/contact.html

Thanks to all who have created milter-greylist! We deployed 1.6 Friday
night, and the results are amazing. We now have milter-greylist running
on our two MX's (using "peer"/"syncaddr"), and it's turning away about
2/3 of our incoming messages (that's unique tuples, counting only the
initial and excluding retry attempts). The volume of spam reaching our
users' INBOXes is way, way down.

Before greylisting we averaged 60-80K messages per day here. Now as I
said only 20-30K are getting through to our other filters. Memory used
is about 30MB resident and 200-300MB total (virtual); greylist.db is at
about 175K lines. (greylist 1h, autowhite 42d, timeout 2d) I was worried
about how big this would get; those numbers are very manageable.

--
Brent J. Nordquist <b-nordquist@...> N0BJN
Other contact information: http://kepler.its.bethel.edu/~bjn/contact.html

On Thu, Feb 03, 2005 at 10:17:45AM +0100, Enrico Scholz wrote:
> I have attached two patches against 1.6 fixing the following issues:

Interesting! These are just what the SPEC I use does also. I'm in favor
of this being applied.

--
Brent J. Nordquist <b-nordquist@...> N0BJN
Other contact information: http://kepler.its.bethel.edu/~bjn/contact.html

I found my problem. There was an error in one of my whitelist lines. When I
converted to 1.75, I edited the conf and had a syntax error.  When an error is
found, it looks like milter-greylist falls back on defaults.  IAC, I fixed the
error, ran milter-greylist -c with a good result, and it's now working as
expected and desired.
--
   Steve

On Thu, 03 Feb 2005 08:19:59 -0600, Steven Stern
<subscribed-lists@...> wrote:

>
>
>I found my problem. There was an error in one of my whitelist lines. When I
>converted to 1.75, I edited the conf and had a syntax error.  When an error is
>found, it looks like milter-greylist falls back on defaults.  IAC, I fixed the
>error, ran milter-greylist -c with a good result, and it's now working as
>expected and desired.

Turns out that wasn't it.  The first couple of incomings got the "wait
00:30:00 ". Then it went random again:

My greylist.cnf file says:

greylist 30s

but.... this is in the log

please come back in 00:30:00
ome back in 00:30:00
please come back in 00:30:00
please come back in 00:29:58
please come back in 00:30:00
please come back in 00:29:56
  back in 00:30:00
please come back in 00:30:00
please come back in 00:30:00
  back in 00:30:00
please come back in 00:27:58
please come back in 00:27:38
please come back in 00:30:00
please come back in 00:01:00
please come back in 00:25:12
  back in 00:24:58
  back in 00:23:36
please come back in 00:22:23
please come back in 00:22:21
please come back in 00:01:00
please come back in 00:01:00
please come back in 00:22:49
please come back in 00:20:04
please come back in 00:21:33
please come back in 00:17:56
  back in 00:18:31
please come back in 00:16:36
please come back in 00:14:08
please come back in 00:14:03
please come back in 00:14:02
please come back in 00:14:02
please come back in 00:14:01
please come back in 00:14:00
please come back in 00:15:18
please come back in 00:12:40
please come back in 00:15:02
please come back in 00:12:26
  back in 00:13:29

--
   Steve

Steven Stern wrote:
> On Thu, 03 Feb 2005 08:19:59 -0600, Steven Stern
> <subscribed-lists@...> wrote:
>
>
>>
>>I found my problem. There was an error in one of my whitelist lines. When I
>>converted to 1.75, I edited the conf and had a syntax error.  When an error is
>>found, it looks like milter-greylist falls back on defaults.  IAC, I fixed the
>>error, ran milter-greylist -c with a good result, and it's now working as
>>expected and desired.
>
>
> Turns out that wasn't it.  The first couple of incomings got the "wait
> 00:30:00 ". Then it went random again:
>
> My greylist.cnf file says:
>
> greylist 30s
>
> but.... this is in the log
>
> please come back in 00:30:00
> ome back in 00:30:00
> please come back in 00:30:00
> please come back in 00:29:58
> please come back in 00:30:00
> please come back in 00:29:56
>  back in 00:30:00
> please come back in 00:30:00
> please come back in 00:30:00
>  back in 00:30:00
> please come back in 00:27:58
> please come back in 00:27:38
> please come back in 00:30:00
> please come back in 00:01:00
> please come back in 00:25:12
>  back in 00:24:58
>  back in 00:23:36
> please come back in 00:22:23
> please come back in 00:22:21
> please come back in 00:01:00
> please come back in 00:01:00
> please come back in 00:22:49
> please come back in 00:20:04
> please come back in 00:21:33
> please come back in 00:17:56
>  back in 00:18:31
> please come back in 00:16:36
> please come back in 00:14:08
> please come back in 00:14:03
> please come back in 00:14:02
> please come back in 00:14:02
> please come back in 00:14:01
> please come back in 00:14:00
> please come back in 00:15:18
> please come back in 00:12:40
> please come back in 00:15:02
> please come back in 00:12:26
>  back in 00:13:29
>

Do the entries that are not 00:30:00 match up with a previous entry?
I've seen a few overzeleous mail servers that are retrying every minute,
and each time they get a 'please come back in [time remaining]'
incremented for the time they have left.

At 08:22 AM 2.3.2005 -0800, Mike Robinson wrote:
>
>>
>
>Do the entries that are not 00:30:00 match up with a previous entry?
>I've seen a few overzeleous mail servers that are retrying every minute,
>and each time they get a 'please come back in [time remaining]'
>incremented for the time they have left.
>

That's what I thought about this one. Look & compare the header & message
ID, etc.


Happy trails,
Jack L. Stone

System Admin
Sage-american

At 08:37 AM 2.3.2005 +0100, manu@... wrote:
>
>Hi
>
>According to this, we'll soon have to find a new idea for filtering spam
>efficiently:
>
>http://news.com.com/Experts+Zombie+trick+set+to+send+spam+sky-high/2100-
>7349_3-5560664.html?tag=nefd.top
>
>Summary: new spam engines don't send spam directly but rather use ISP
>SMTP servers. That will workaround greylisting, as the ISP SMTP server
>will retry sending.
>
>--
>Emmanuel Dreyfus
>http://hcpnet.free.fr/pubz
>manu@...
>

Emmanuel: On installing greylisting for the first time, it was also my
first thought that it would be good until the bad guys find a workaround. I
agree that GL has been a fantastic tool to-date and has lifted a great load
off of the other tools that eat big resources like spamassassin. The
present SA-3.0+ has constant complaints about hogging huge amounts of
memory -- causing some to revert back to 2.5x or 2.6x -- at the sake of
losing some effectiveness of the advances made by 3.0+.

It is also why I was hoping to see more expansion like the callback/mx IP
matching somehow, etc. In this war, no static anti-spam tool will last long
without change with counter-actions.

My $0.02 for the obvious....


Happy trails,
Jack L. Stone

System Admin
Sage-american

Hi,

>>>>> On Tue, 01 Feb 2005 13:14:17 +0100
>>>>> Cyril Guibourg <cg+milter-greylist@...> said:

cg> Just to tell you that I just submitted a devel version of the port for
FreeBSD.
cg> http://www.freebsd.org/cgi/query-pr.cgi?pr=76954

I've just committed it.  Thanks!

Sincerely,

--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
ume@...  ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/

Enrico Scholz <greylist-milter@...> wrote:

> +             if (initgroups(conf.c_user, pw->pw_gid) != 0) {
> +                     syslog(LOG_ERR, "%s: can not change supplementary
groups: %s\n",
> +                            argv[0], strerror(errno));
> +                     exit(EX_OSERR);
> +             }
> +
> +             if (setgid(pw->pw_gid) != 0 ||
> +                 setegid(pw->pw_gid) != 0) {
> +                     syslog(LOG_ERR, "%s: cannot change GID: %s\n",
> +                         argv[0], strerror(errno));
> +                     exit(EX_OSERR);
> +             }
> +

I'm ready to commit that, but I'm concerned about initgroups() not being
portable. Any input on that? How should it work on systems without
initgroups?

--
Emmanuel Dreyfus
Un bouquin en français sur BSD:
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@...

On Thu, 03 Feb 2005 08:22:24 -0800, Mike Robinson <mrobinson@...> wrote:

>Do the entries that are not 00:30:00 match up with a previous entry?
>I've seen a few overzeleous mail servers that are retrying every minute,
>and each time they get a 'please come back in [time remaining]'
>incremented for the time they have left.

Not all of them.... but I've set the interval to 30 seconds.
--
   Steve

--- manu@... wrote:

> Enrico Scholz <greylist-milter@...> wrote:
>
> > +             if (initgroups(conf.c_user,
> pw->pw_gid) != 0) {
> > +                     syslog(LOG_ERR, "%s: can not
> change supplementary groups: %s\n",
> > +                            argv[0],
> strerror(errno));
> > +                     exit(EX_OSERR);
> > +             }
> > +
> > +             if (setgid(pw->pw_gid) != 0 ||
> > +                 setegid(pw->pw_gid) != 0) {
> > +                     syslog(LOG_ERR, "%s: cannot
> change GID: %s\n",
> > +                         argv[0],
> strerror(errno));
> > +                     exit(EX_OSERR);
> > +             }
> > +
>
> I'm ready to commit that, but I'm concerned about
> initgroups() not being
> portable. Any input on that? How should it work on
> systems without
> initgroups?

Remember my patch for seteuid?  Here again, I think
that setregid is more portable than setegid.  And only
setgid exists on absolutely any system.  I think that
configure check should be added for setregid, setegid
and initgroups existence.

Eugene



__________________________________
Do you Yahoo!?
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
http://info.mail.yahoo.com/mail_250

Eugene Crosser <egcrosser@...> wrote:

> Remember my patch for seteuid?  Here again, I think
> that setregid is more portable than setegid.  And only
> setgid exists on absolutely any system.  I think that
> configure check should be added for setregid, setegid
> and initgroups existence.

Sure, but what do we do if it does not exist?

--
Emmanuel Dreyfus
Le cahier de l'admin BSD 2eme ed. est dans toutes les bonnes librairies
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@...

On Sat, Jan 15, 2005 at 08:49:46AM +0100, manu@... wrote:

> > Does it make sense to add a lightweight version of teergrube to
> > greylisting?  You could do something like sleep(10) the first time a
> > tuple shows up, and not do the sleep() if the tuple comes back later
> > or is whitelisted.
>
> I beleive you can do that in sendmail.cf, can't you?

of course, it's the greeting feature, i.e.
FEATURE(`greet_pause', `6000')  dnl 6 seconds

best regards
hans

--

--- manu@... wrote:

> Eugene Crosser <egcrosser@...> wrote:
>
> > Remember my patch for seteuid?  Here again, I
> think
> > that setregid is more portable than setegid.  And
> only
> > setgid exists on absolutely any system.  I think
> that
> > configure check should be added for setregid,
> setegid
> > and initgroups existence.
>
> Sure, but what do we do if it does not exist?

On systems where neither setregid nor setegid exist,
setgid sets *both* gid and egid.  Hopefully :-)  As
far as I know, anyway.

Even if not, well, then nothing can be done, we just
continue running with elevated priviledges...

Eugene



__________________________________
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail

On Thu, 03 Feb 2005 11:43:12 -0600, "Jack L. Stone" <jacks@...>
wrote:

>
>At 08:22 AM 2.3.2005 -0800, Mike Robinson wrote:
>>
>>>
>>
>>Do the entries that are not 00:30:00 match up with a previous entry?
>>I've seen a few overzeleous mail servers that are retrying every minute,
>>and each time they get a 'please come back in [time remaining]'
>>incremented for the time they have left.
>>
>
>That's what I thought about this one. Look & compare the header & message
>ID, etc.

Indeed, they were working off an old delay.

On the 30 minutes vs 30 seconds issue,
    -w 30s
on the command line generates the correct interval, but

    greylist 30s

in greylist.conf seems to be the same as 30m.
--
   Steve

Steven Stern <subscribed-lists@...> wrote:

> Indeed, they were working off an old delay.
>
> On the 30 minutes vs 30 seconds issue,
>    -w 30s
> on the command line generates the correct interval, but
>
>    greylist 30s
>
> in greylist.conf seems to be the same as 30m.

That should be easy to track down and fix. Will you contribute a fix for
it?

--
Emmanuel Dreyfus
Publicité subliminale: achetez ce livre!
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@...

On Fri, 4 Feb 2005 00:12:16 +0100, manu@... wrote:

>
>Steven Stern <subscribed-lists@...> wrote:
>
>> Indeed, they were working off an old delay.
>>
>> On the 30 minutes vs 30 seconds issue,
>>    -w 30s
>> on the command line generates the correct interval, but
>>
>>    greylist 30s
>>
>> in greylist.conf seems to be the same as 30m.
>
>That should be easy to track down and fix. Will you contribute a fix for
>it?


It looks like all time values get parsed in humanized_atoi(), but I think that
code is right because it works with the -w command. I'm looking around, and I
think it's in conf_yacc.c, so now I'm trying to understand the yacc lexicon.
Elegant code, but hard to trace.
--
   Steve

Hi,

I installed milter_greylist 1.6 on my fc3 linux
system,  It looks running well.  My question is:
should I run it as root or as smmsp?  Currently, I run
it as root. I tried to run it as smmsp, but it seems
that it does not do anything.

What should I do if I want to run it as smmsp in
addition to uncomment the line
#user "smmsp"
in the config file greylist.conf?
What are the advantages and disadvantages of running
it as smmsp or as root?

Thanks!

Harvey



__________________________________
Do you Yahoo!?
Yahoo! Mail - 250MB free storage. Do more. Manage less.
http://info.mail.yahoo.com/mail_250

On Fri, Feb 04, 2005 at 08:00:12AM -0800, H Li wrote:
> I installed milter_greylist 1.6 on my fc3 linux
> system,  It looks running well.  My question is:
> should I run it as root or as smmsp?  Currently, I run
> it as root. I tried to run it as smmsp, but it seems
> that it does not do anything.

It's because it can't write anymore to the dump file, which is
owned by root because you already ran milter-greylist as root.

> What should I do if I want to run it as smmsp in
> addition to uncomment the line
> #user "smmsp"
> in the config file greylist.conf?
> What are the advantages and disadvantages of running
> it as smmsp or as root?

Running as non root is better on the security front if a
security hole is discovered in milter-greylist.

--
Emmanuel Dreyfus
manu@...

--- Emmanuel Dreyfus <manu@...> wrote:

> On Fri, Feb 04, 2005 at 08:00:12AM -0800, H Li
> wrote:
> > I installed milter_greylist 1.6 on my fc3 linux
> > system,  It looks running well.  My question is:
> > should I run it as root or as smmsp?  Currently, I
> run
> > it as root. I tried to run it as smmsp, but it
> seems
> > that it does not do anything.
>
> It's because it can't write anymore to the dump
> file, which is
> owned by root because you already ran
> milter-greylist as root.
>
> > What should I do if I want to run it as smmsp in
> > addition to uncomment the line
> > #user "smmsp"
> > in the config file greylist.conf?

Then, can I just change the ownershihp of greylist.db
to smmsp to run it as smmsp?  Do I need to change the
ownership of milter-greylist.sock?  or should I stop
it first, delete the db and sock files, then start it?

Thanks!

Harvey

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com