Milter-greylist

Le mar 21/11/2006 à 13:40, manu@... a écrit :
> 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?

Spam is generally send with no X-priority (same as 3) or X-priority 3 so
I don't really expect spammers to send with X priority 5 and 4. So  4
and 5 should be processed same as 3. But I can expect that user in a
hurry could send with 1 or 2.

Actually I use the following ACL to pass without delay :

rcpt /.*+XXX@.../

where XXX is a secret known by usual sender to mydomain.fr
sendmail treat william+XXX@... same as william@... so
I have nothing to do in /etc/mail/aliases (or any users table)

The problem with +XXX is that some ISP or webmail refuse an address with
+XXX
The X-priority proposal is an idea to replace +XXX by a well known
header and
the better related choice is X-priority (or M$ one).

Generally private site scan queue with a -q15m or -q30m period but also
many ISP scan mail queue with a 2 minutes period almost on the second
(even third ?) try; if it failed then they move deferred mail to a queue
with a longer period (-q1h,q4h or more). 




> 
> > 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.
Yes I agree.
> 
> 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 ...

It suits for me.

> 
> -- 
> Emmanuel Dreyfus
> http://hcpnet.free.fr/pubz
> manu@...
> 
> 
> 
>  
-- 
Christian Pélissier
Office National d'Études et de Recherches Aérospatiales
BP 72 92322 Chatillon
Tel: 33 1 46 73 44 19, Fax: 33 1 46 73 41 50