Milter-greylist

Christian PELISSIER <Christian.Pelissier@...> wrote:

> Idea one
> ========
(snip) 
> So a good (or a bad) idea could be to give the senders some control on
> the delay
> by adapting the waiting time (option -w) according to the X-Priority
> header (needs to inform senders to be efficient) of icoming mails.

How long do you expect spammers to send all messages with X-Priority: 5?
 
> Idea Two
> ========
> Many spam come now as a gif, jpeg or png containing text. If we apply
> the same idea as above delaying longer by adding a new delay to the
> previous one when a mail come with attachements

Well, that can make sense, but perhaps it can be made more general: we
could have ACL clauses based on match against headers and body. We could
also use the length of the message.

Something such as:
acl greylist body /^Content-Type: image.gif/ len_lower 4096 greylist 12h

Note that it would allow you to implement your idea one.

Problem: that decision must be done at the DATA stage, while most of
milter-greylist decisions occur at the RCPT stage. If we move in that
direction, we will have in fact two ACL sets, one evaluated at RCPT, and
one evaluated at DATA. How can we make that simple to understand?

Idea: we introduce rcpt_acl and data_acl, and we tell acl is deprecated:
rcpt_acl greylist ...
data_acl greylist ...

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