Milter-greylist

Hi,

man greylist.conf states the following about data stage acls:

	DATA-STAGE ACL

	  (...) DATA-stage ACL cannot use the greylist action (...)


Returning 451 should be permitted after DATA so is there maybe another
technical reason for not allowing `greylist' in `dacl'?


Thanks,

Petar

Petar Bogdanovic a \ufffdcrit :
> Hi,
> 
> man greylist.conf states the following about data stage acls:
> 
> 	DATA-STAGE ACL
> 
> 	  (...) DATA-stage ACL cannot use the greylist action (...)
> 
> 
> Returning 451 should be permitted after DATA so is there maybe another
> technical reason for not allowing `greylist' in `dacl'?
> 

Because at this point all the "RCPT TO:" commands have already been 
accepted, so your only choice is to accept or reject the message as a 
whole, and not on a per-recipient basis, which is the way greylisting 
operates.

-- 
Ce message a ete verifie par MailScanner
pour des virus ou des polluriels et rien de
suspect n'a ete trouve.

Petar Bogdanovic <petar@...> wrote:

> Returning 451 should be permitted after DATA so is there maybe another
> technical reason for not allowing `greylist' in `dacl'?

Well, the biggest difficulty is to define the proprer behavior:

What should we store in the greylist for a multiple-recipient message?
Would another message, with only some of the recipient, be considered as
a re-expedition?

What about if RCPT-stage ACL set speficy that some recipient should skip
greylisting?


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

On Sun, Sep 14, 2008 at 06:23:36AM +0200, manu@... wrote:

> What should we store in the greylist for a multiple-recipient message?

At present the greylist contains one record per recipient. I think this
behaviour would not need to change.

> Would another message, with only some of the recipient, be considered as
> a re-expedition?

Yes, per recipient. No need to change here neither.

> What about if RCPT-stage ACL set speficy that some recipient should skip
> greylisting?

If you think of it as stages, a racl whitelist only means, that the
sender can step to the data stage, without further investigation at the
rcpt to stage.

At the moment a whitelisted recipient also becomes blacklisted if an
according dacl entry exists. Finally this is a configuration issue and
the mta administrator must be aware that data acls can overwrite
recipient whitelists.

The pro is obvious. If it was possible to greylist at the data stage,
many additional spam checks on the message body were possible.

Cheers, Manuel

> The pro is obvious. If it was possible to greylist at the data stage,
> many additional spam checks on the message body were possible.

But what's the use for greylisting after the data stage?  Why not only
accept or refuse (and perhaps temporarily black/whitelist the triplet)?
After the data stage, you have seen the whole email, you can make
intelligent decisions.  As I see it (and please tell me if I am wrong),
greylisting after the data phase wins you nothing, but wastes bandwidth
and other resources (yours!).

Akos

-- 
Akos Szalkai <szalkai@...>
Principal IT Consultant, CISA
2F 2000 Szamitastechnikai es Szolgaltato Kft.
Tel: (+36-1)-4887700  Fax: (+36-1)-4887709  WWW: http://www.2f.hu/

On Mon, Sep 15, 2008 at 02:30:43PM +0200, Akos Szalkai wrote:

> But what's the use for greylisting after the data stage?  Why not only
> accept or refuse (and perhaps temporarily black/whitelist the triplet)?

At the data stage you could use various additional spam identifying methods besides
ip, sender and recipient.


> As I see it (and please tell me if I am wrong), greylisting after the
> data phase wins you nothing, but wastes bandwidth and other resources
> (yours!).

That's the nature of data stage acl's. But I think the possibility to
read the message before greylisting would outweigh the disadvantages.


IMHO this would be a quite powerful feature and improves the dacl's. But
if someone doesn't need it, he stays with the racls.

On Mon, Sep 15, 2008 at 8:06 PM, Manuel Badzong <manuel@...> wrote:
> On Mon, Sep 15, 2008 at 02:30:43PM +0200, Akos Szalkai wrote:
>
>> But what's the use for greylisting after the data stage?  Why not only
>> accept or refuse (and perhaps temporarily black/whitelist the triplet)?
>
> At the data stage you could use various additional spam identifying methods besides
> ip, sender and recipient.

But if you identify it as spam with your "additional methods", don't
you want to blacklist it then? What's the point to greylist (ask them
to resend) if you already know it's spam?

-- 
/peter

On Mon, Sep 15, 2008 at 08:30:32PM +0200, shuttlebox wrote:
> On Mon, Sep 15, 2008 at 8:06 PM, Manuel Badzong <manuel@...> wrote:
> > On Mon, Sep 15, 2008 at 02:30:43PM +0200, Akos Szalkai wrote:
> >
> >> But what's the use for greylisting after the data stage?  Why not only
> >> accept or refuse (and perhaps temporarily black/whitelist the triplet)?
> >
> > At the data stage you could use various additional spam identifying methods besides
> > ip, sender and recipient.
> 
> But if you identify it as spam with your "additional methods", don't
> you want to blacklist it then? What's the point to greylist (ask them
> to resend) if you already know it's spam?

That's the advantage of conditional greylisting: A non-human content
inspector -- like a public DNSBL -- can always be wrong, so just
greylisting the sender still leaves a door open for real MTAs to deliver
their mail. At the same time you don't have to greylist _everyone_.

Imagine the following scenery:

	spamdsock "/var/run/spamd.sock"

	dacl greylist  spamd-score >  5 delay  6h
	dacl greylist  spamd-score > 10 delay 12h
	dacl greylist  spamd-score > 15 delay 24h
	dacl blacklist spamd-score > 20


That's called `adaptive greylisting' and is already implemented in
exim-sa:

	http://marc.merlins.org/linux/exim/sa.html


However, I do understand that this would interfere with all those
whitelist statements you defined before the dacl, but such overrides are
already permitted by milter-greylist by allowing `dacl blacklist'.


Thanks,

Petar

Petar Bogdanovic <petar@...> wrote:

> Imagine the following scenery:
> 
>       spamdsock "/var/run/spamd.sock"
> 
>       dacl greylist  spamd-score >  5 delay  6h
>       dacl greylist  spamd-score > 10 delay 12h
>       dacl greylist  spamd-score > 15 delay 24h
>       dacl blacklist spamd-score > 20

That's cute. If you think you are going to convince me that way, you are
not wrong! :-)

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

Emmanuel Dreyfus <manu@...> wrote:

> That's cute. If you think you are going to convince me that way, you are
> not wrong! :-)

Following-up myself: I just need to be convinced it is useful to start
implementing it. If someone else contribute a patch for that, I'll be
glad to integrate it (even if I would not see how it could be useful).

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

2008/9/15 Petar Bogdanovic <petar@...>:
> Imagine the following scenery:
>
>        spamdsock "/var/run/spamd.sock"
>
>        dacl greylist  spamd-score >  5 delay  6h
>        dacl greylist  spamd-score > 10 delay 12h
>        dacl greylist  spamd-score > 15 delay 24h
>        dacl blacklist spamd-score > 20

FYI: milter-greylist expires unsuccessful entries in not in 'timeout'
time, but in 'delay + timeout' time (and 'timeout' is only a global
setting). Hence in this context, you're ensuring that tuples from
messages which are indeed spam are going to waste space in your
database longer than those that are less likely to be spam.

C.

On Tue, Sep 16, 2008 at 08:45:09AM -0400, Greg Troxel wrote:
> 
>    spamdsock "/var/run/spamd.sock"
> 
>    dacl greylist  spamd-score >  5 delay  6h
>    dacl greylist  spamd-score > 10 delay 12h
>    dacl greylist  spamd-score > 15 delay 24h
>    dacl blacklist spamd-score > 20
> 
> I would write the scores somewhat differently, doing
> 
>  > 0 delay 30m
>  > 2 delay 4h
>  > 4 delay 12h
>  > 6 reject altogether
> 
> 
> The key question is how milters interact.  Currently I run
> milter-greylist and spamass-milter, and spamassassin only sees things
> after greylist says ok.

With the feature described above, you could drop spamass-milter and you
would still be able to racl the most badboys through DNSBLs before doing a
full featured spamassassin-dacl on the rest.

The following patch enables greylisting at the data stage. A message for multiple recipients will pass the greylist as soon as all recipients have valid

The following patch enables greylisting at the data stage. A message for
multiple recipients will pass the greylist as soon as all recipients
have valid tuples.

To make it work the default racl needs to be set to whitelist.

regards, Manuel