Milter-greylist

Hi,

thank you for providing milter-greylist and tarpit.

Am 03.09.09 um 15:26 schrieb Kouhei Sutou:

>     acl whitelist tarpit 65s
>
>   This ACL means that clients that can wait a response in
>   65s are whitelisted. If the clients access again, they are
>   acceptted without lazy response because they are in
>   auto-whitelist.

It seems that this auto-whitelisting does not work. Assumed that the
sender is able to wait, messages are accepted after waiting, but
subsequent messages with identical host,from,rcpt tuples have to wait
again and again. No AUTO line (no line at all) is put into the DB.

With a test config snippet

racl whitelist rcpt /b/ tarpit 10s

debugging output is

Jun 19 15:58:23 host milter-greylist: created:  x.x.x.x from <a> to <b> delayed for 00:30:00
Jun 19 15:58:33 host milter-greylist: removed: x.x.x.x from <a> to <b>
Jun 19 15:58:33 host sm-mta[26004]: s5JDwMg9026004: from=<a>, size=217, class=0, nrcpts=1, msgid=<id@host>, proto=ESMTP, daemon=MTA-v6, relay=relay [x.x.x.x]
Jun 19 15:58:33 host sm-mta[26004]: s5JDwMg9026004: Milter add: header: X-Greylist: Recipient e-mail whitelisted, Sender IP whitelisted by MX, Message whitelisted by tarpit 10s, ACL 127 matched, not delayed by milter-greylist-4.5.11 (host [y.y.y.y]); Thu, 19 Jun 2014 15:58:33 +0200 (CEST)

Do I miss something? All I need is the documented behaviour.
At first. ;-)

Best regards,
Frank.

Hi,

> Am 03.09.09 um 15:26 schrieb Kouhei Sutou:
>
> >     acl whitelist tarpit 65s
> >
> >   This ACL means that clients that can wait a response in
> >   65s are whitelisted. If the clients access again, they are
> >   acceptted without lazy response because they are in
> >   auto-whitelist.
>
> It seems that this auto-whitelisting does not work. Assumed that the
> sender is able to wait, messages are accepted after waiting, but
> subsequent messages with identical host,from,rcpt tuples have to wait
> again and again. No AUTO line (no line at all) is put into the DB.
>
> With a test config snippet
>
> racl whitelist rcpt /b/ tarpit 10s
>
> debugging output is
>
> Jun 19 15:58:23 host milter-greylist: created:  x.x.x.x from <a> to <b> delayed for 00:30:00
> Jun 19 15:58:33 host milter-greylist: removed: x.x.x.x from <a> to <b>
> Jun 19 15:58:33 host sm-mta[26004]: s5JDwMg9026004: from=<a>, size=217, class=0, nrcpts=1, msgid=<id@host>, proto=ESMTP, daemon=MTA-v6, relay=relay [x.x.x.x]
> Jun 19 15:58:33 host sm-mta[26004]: s5JDwMg9026004: Milter add: header: X-Greylist: Recipient e-mail whitelisted, Sender IP whitelisted by MX, Message whitelisted by tarpit 10s, ACL 127 matched, not delayed by milter-greylist-4.5.11 (host [y.y.y.y]); Thu, 19 Jun 2014 15:58:33 +0200 (CEST)
>
> Do I miss something? All I need is the documented behaviour.

I had a look at milter-greylist.c, line 802ff:

  if (sleep_duration > 0) {
          if (sleep_duration > priv->priv_max_tarpitted)
                  priv->priv_max_tarpitted = sleep_duration;
          priv->priv_total_tarpitted += sleep_duration;
          sleep(sleep_duration);
  } else {
      if (priv->priv_sr.sr_whitelist & EXF_WHITELIST) {
          tuple.updatetype = TU_AUTOWHITE;
          mg_tuple_update(&tuple);
          }
  }

it seems to me, after the "sleep(sleep_duration)" the entry would have to
be autowhitelisted, just if the the sender continues to send the mail. How
to accomplish this? real_envrcpt() does not get called again in this
session, and the entry is never autowhitelisted.

May someone have a look at it? I hesitate to put my dirty fingers on this
code. ;-)

Best regards,
Frank.

On Mon, Jun 23, 2014 at 12:28:24PM +0200, Frank Doepper fd@... [milter-greylist] wrote:
> May someone have a look at it? I hesitate to put my dirty fingers on this
> code. ;-)

Well, I did not write that part. Anyone?

-- 
Emmanuel Dreyfus
manu@...

Am 23.06.14 um 12:19 schrieb Emmanuel Dreyfus manu-S783fYmB3Ccdnm+yROfE0A@p...:

> On Mon, Jun 23, 2014 at 12:28:24PM +0200, Frank Doepper fd@... [milter-greylist] wrote:
> > May someone have a look at it? I hesitate to put my dirty fingers on this
> > code. ;-)
>
> Well, I did not write that part. Anyone?

I think I've got it. Patch attached.

Frank.

Frank Doepper fd@... [milter-greylist]
<milter-greylist@yahoogroups.com> wrote:

> > Well, I did not write that part. Anyone?
> I think I've got it. Patch attached.

Patch does not apply. What milter-greylist version are you using?
Please redo with diff -U16 so that I can be sure where it belongs in the
file.

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

Hi,

In <alpine.LNX.2.02.1406212302210.1949@...>
  "[milter-greylist] tarpit auto-whitelisting" on Sat, 21 Jun 2014 23:05:05 +0200,
  "Frank Doepper fd@... [milter-greylist]" <milter-greylist@yahoogroups.com> wrote:

> Am 03.09.09 um 15:26 schrieb Kouhei Sutou:
> 
>>     acl whitelist tarpit 65s
>>
>>   This ACL means that clients that can wait a response in
>>   65s are whitelisted. If the clients access again, they are
>>   acceptted without lazy response because they are in
>>   auto-whitelist.
> 
> It seems that this auto-whitelisting does not work. Assumed that the
> sender is able to wait, messages are accepted after waiting, but
> subsequent messages with identical host,from,rcpt tuples have to wait
> again and again. No AUTO line (no line at all) is put into the DB.
> 
> With a test config snippet
> 
> racl whitelist rcpt /b/ tarpit 10s
> 
> debugging output is
> 
> Jun 19 15:58:23 host milter-greylist: created:  x.x.x.x from <a> to <b> delayed for 00:30:00
> Jun 19 15:58:33 host milter-greylist: removed: x.x.x.x from <a> to <b>
> Jun 19 15:58:33 host sm-mta[26004]: s5JDwMg9026004: from=<a>, size=217, class=0, nrcpts=1, msgid=<id@host>, proto=ESMTP, daemon=MTA-v6, relay=relay [x.x.x.x]
> Jun 19 15:58:33 host sm-mta[26004]: s5JDwMg9026004: Milter add: header: X-Greylist: Recipient e-mail whitelisted, Sender IP whitelisted by MX, Message whitelisted by tarpit 10s, ACL 127 matched, not delayed by milter-greylist-4.5.11 (host [y.y.y.y]); Thu, 19 Jun 2014 15:58:33 +0200 (CEST)
> 
> Do I miss something? All I need is the documented behaviour.

Could you also provide expected debugging output?
I can't understand about the expected behavior yet.


Thanks,
--
kou

Am 24.06.14 um 02:32 schrieb manu@......:

> Frank Doepper fd@... [milter-greylist]
> <milter-greylist@yahoogroups.com> wrote:
>
> > > Well, I did not write that part. Anyone?
> > I think I've got it. Patch attached.
>
> Patch does not apply. What milter-greylist version are you using? Please
> redo with diff -U16 so that I can be sure where it belongs in the file.

Sure? I use 4.3.9, but the patch applies to 4.4.3 and 4.5.11, too.

I redo it with -U16 and put it there: http://taz.de/~fd/stuff/tarpit.patch

Best regards,
Frank.

Am 24.06.14 um 11:31 schrieb Kouhei Sutou:

> Could you also provide expected debugging output?
> I can't understand about the expected behavior yet.

I would expect something like:

Jun 24 13:17:19 host milter-greylist: s5OBHIxX025868: skipping greylist because tarpit is requested, (from=<from@...>, rcpt=<to@...>, addr=host.example.com[8.8.8.8]) ACL 237
Jun 24 13:17:19 host milter-greylist: s5OBHIxX025868: addr 8.8.8.8 from <from@...> rcpt <to@...>: autowhitelisted for another 36:00:00

Maybe this was not intended by your code, but I interpreted the docs ("If
the clients access again, they are accepted without lazy response because
they are in auto-whitelist." this way.

Best regards,
Frank.

Hi,

three years ago I suggested a patch:

> I redo it with -U16 and put it there:
> http://taz.de/~fd/stuff/tarpit.patch

> Am 24.06.14 um 11:31 schrieb Kouhei Sutou:
>
> > Could you also provide expected debugging output?
> > I can't understand about the expected behavior yet.
>
> I would expect something like:
>
> Jun 24 13:17:19 host milter-greylist: s5OBHIxX025868: skipping greylist because tarpit is requested, (from=<from-hcDgGtZH8xNBDgjK7y7TUQ@...>, rcpt=<to-hcDgGtZH8xNBDgjK7y7TUQ@...>, addr=host.example.com[8.8.8.8]) ACL 237
> Jun 24 13:17:19 host milter-greylist: s5OBHIxX025868: addr 8.8.8.8 from <from-hcDgGtZH8xNBDgjK7y7TUQ@...> rcpt <to-hcDgGtZH8xNBDgjK7y7TUQ@...>: autowhitelisted for another 36:00:00
>
> Maybe this was not intended by your code, but I interpreted the docs ("If
> the clients access again, they are accepted without lazy response because
> they are in auto-whitelist." this way.

I have milter-greylist running with this patch for years on all my
machines and would appreciate it to be included in the main repo.

best regards,
Frank

Frank Doepper fd@... [milter-greylist]
<milter-greylist@yahoogroups.com> wrote:

> three years ago I suggested a patch:
> 
> > I redo it with -U16 and put it there:
> > http://taz.de/~fd/stuff/tarpit.patch

Sorry for ignoring it for so long.

It changes the behavior, should there be an option for this? Anyone has
an opinion on the topic?

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

On July 11, 2017 5:37:30 AM GMT+02:00, "manu@... [milter-greylist]" <milter-greylist@yahoogroups.com> wrote:
>Frank Doepper fd@... [milter-greylist]
><milter-greylist@yahoogroups.com> wrote:
>
>> three years ago I suggested a patch:
>> 
>> > I redo it with -U16 and put it there:
>> > http://taz.de/~fd/stuff/tarpit.patch
>
>Sorry for ignoring it for so long.
>
>It changes the behavior, should there be an option for this? Anyone has
>an opinion on the topic?

I'd say yes, and defaulting to off - for the sake of least-surprise principle when upgrading. Otherwise, the idea is good. 

Might make even more sense in rulesets I published on github that track "spamminess score" in a variable, to suggest that an insistent host might be a good one (so not instant AWL for all that pass it, but more likely to get WLed).

Jim
--
Typos courtesy of K-9 Mail on my Redmi Android

On Tue, Jul 11, 2017 at 05:37:30AM +0200, manu@... [milter-greylist] wrote:
> Frank Doepper fd@... [milter-greylist]
> <milter-greylist@yahoogroups.com> wrote:
> 
> > three years ago I suggested a patch:
> > 
> > > I redo it with -U16 and put it there:
> > > http://taz.de/~fd/stuff/tarpit.patch
> 
> Sorry for ignoring it for so long.
> 
> It changes the behavior, should there be an option for this? Anyone has
> an opinion on the topic?

my rule of thumb is: if a new feature breaks compatibility in existing
installations, the new feature should default to OFF, with a commandline
(or other) switch to enable it for those who want it.

-- 
---- Fred Smith -- fredex@... -----------------------------
                        The Lord is like a strong tower. 
             Those who do what is right can run to him for safety.
--------------------------- Proverbs 18:10 (niv) -----------------------------