Milter-greylist

Here is our latest development snapshot:

http://ftp.espci.fr/pub/milter-greylist/milter-greylist-3.1.1.tgz
MD5 (milter-greylist-3.1.1.tgz) = 7bdb3d2230d7144a9985f6a3f84fd013

That's for developement. I'm not sure it even works :-)

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

Some ideas for the next milter-greylist release.

Idea one
========
Some users complains sometimes about greylisting delays. Milter-greylist
allow many
ways to satisfy them but it needs to modify greylist.conf and restart.

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.

Thunderbird allow us to define the following priorities :

X-Priority: 1 (Highest)
X-Priority: 2 (High)
X-Priority: 3 (Normal)
X-Priority: 4 (Low)
X-Priority: 5 (Lowest)

MicroSoft use 

X-MSMail-Priority: High
X-MSMail-Priority: Normal
X-MSMail-Priority: ...
...

So having in greylist.conf

greylist 15m

and take care of priority with 

priority_highest    -13m
priority_high       -10m
priority_normal     +0
priority_low        +45m
priority_lowest     +4h

(I dont know if it's better to give relative or absolute value)


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

ct_gif_add	1h
ct_jpeg_add	30m
ct_png_add	5m
ct_htm_add	5m
ct_doc_add	5m


It needs to scan the body searching for :

Content-Type: image/gif
Content-Type: image/jpeg
etc.

Hi,

The headers you are referring to are transferred at the stage later than
the greylisting is happening thus are not possible to be used.

For your ideas to work milter-greylist would have to work throughout the
SMTP transaction, wait until the DATA stage is over and only then
respond with a temporary failure, which is an "expensive" process and
IMHO would defeat the "cheapness" of the current implementation.

Best regards,

Ranko

On Tue, 2006-11-21 at 11:15 +0100, Christian PELISSIER wrote:
> Some ideas for the next milter-greylist release.
> 
> Idea one
> ========
> Some users complains sometimes about greylisting delays.
> Milter-greylist
> allow many
> ways to satisfy them but it needs to modify greylist.conf and restart.
> 
> 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.
> 
> Thunderbird allow us to define the following priorities :
> 
> X-Priority: 1 (Highest)
> X-Priority: 2 (High)
> X-Priority: 3 (Normal)
> X-Priority: 4 (Low)
> X-Priority: 5 (Lowest)
> 
> MicroSoft use 
> 
> X-MSMail-Priority: High
> X-MSMail-Priority: Normal
> X-MSMail-Priority: ...
> ...
> 
> So having in greylist.conf
> 
> greylist 15m
> 
> and take care of priority with 
> 
> priority_highest -13m
> priority_high -10m
> priority_normal +0
> priority_low +45m
> priority_lowest +4h
> 
> (I dont know if it's better to give relative or absolute value)
> 
> 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
> 
> ct_gif_add 1h
> ct_jpeg_add 30m
> ct_png_add 5m
> ct_htm_add 5m
> ct_doc_add 5m
> 
> It needs to scan the body searching for :
> 
> Content-Type: image/gif
> Content-Type: image/jpeg
> etc.
> 
> 
> 
> 
>  
-- 
Ranko Zivojnovic
IT Director/CTO          

SpiderNet Services Public Ltd.
Nicosia, Cyprus
Tel:    +357 22 844844
FAX:    +357 22 669470
E-Mail: ranko@...
Web:    www.spidernet.net

Christian PELISSIER wrote:
 > Some users complains sometimes about greylisting delays.
 > [...]
 > Thunderbird allow us to define the following priorities :
 > X-Priority: 1 (Highest)
 > [...]
 > MicroSoft use 
 > X-MSMail-Priority: High
 > [...]

Several other MUAs (e.g. elm) use this one:
Priority: {normal,urgent}

 > So having in greylist.conf
 > 
 > greylist 15m
 > 
 > and take care of priority with 
 > 
 > priority_highest    -13m
 > priority_high       -10m
 > priority_normal     +0
 > priority_low        +45m
 > priority_lowest     +4h

That won't help much.  Typically, mail servers use a queue
interval of 30 minutes (at least that's a common value, and
it's the default for many MTA installations).

So it doesn't really matter much whether you greylist for
15 minutes or for 3 minutes.  In either case it can happen
that the sender will retry sending the message after 30
minutes.  Of course, if the sender's next queue run happens
to be scheduled within a few minutes, then a short grey-
listing interval will help to deliver the message sooner.
But that's not really something to rely on or to guarantee,
i.e. it will probably not satisfy users who are unsatisfied
with their mails being delayed.

When people ask me about the delay problem, my answer is
usually:  Yes, a delay will occur, but only on the _first_
mail between two persons.  After that, the sender is in
the whitelist, so any further communication will not be
delayed.  I think that's acceptable.

Of course there are cases where even the delay on the first
message is not acceptable.  For example, help desks who
have to answer in a timely manner to customer requests,
or mail accounts that receive alert messages from various
sources (that are not known in advance) which have to be
acted upon immediately.  In those cases, the recipients
(and _only_ those) should be exempted from greylisting
completely, which is easy to configure with milter-greylist
ACLs ("acl whitelist rcpt 911@...").  Of course
that might increase the spam level for those recipients,
but that's the deal when you don't want to be greylisted.

 > 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

That won't satisfy your users, I bet.  :-)

Best regards
   Oliver

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.

"anyone new to programming should be kept as far from C++ as
possible;  actually showing the stuff should be considered a
criminal offence" -- Jacek Generowicz

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@...

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

Quick question:
Did the permission requirements for /var/milter-greylist change with
this version?

For some reason I get warnings about the socket path in
/var/milter-greylist being unsafe, using the exact same configuration,
init script, and file/directory ownership as I am using sucessfully
for version 3.0.

When I switch back to using 3.0, it works just fine.

Starting up as root, running as smmsp, on a Fedora FC2 box.
/var/milter-graylist ownership smmsp:smmsp, permissions: 0755
drwxr-xr-x  2 smmsp smmsp 4096 Nov 24 08:59 /var/milter-greylist/

Any ideas?

--- In milter-greylist@yahoogroups.com, manu@... wrote:

>
> Here is our latest development snapshot:
> 
> http://ftp.espci.fr/pub/milter-greylist/milter-greylist-3.1.1.tgz
> MD5 (milter-greylist-3.1.1.tgz) = 7bdb3d2230d7144a9985f6a3f84fd013
> 
> That's for developement. I'm not sure it even works :-)
> 
> -- 
> Emmanuel Dreyfus
> http://hcpnet.free.fr/pubz
> manu@...
>

On Fri, Nov 24, 2006 at 05:04:54PM -0000, count_nerdula wrote:
> For some reason I get warnings about the socket path in
> /var/milter-greylist being unsafe, using the exact same configuration,
> init script, and file/directory ownership as I am using sucessfully
> for version 3.0.
> 
> When I switch back to using 3.0, it works just fine.

You forgot --with-user flag to configure?

-- 
Emmanuel Dreyfus
manu@...

That's entirely possable.  I hadn't used it while compiling for 3.0  
either but maybe that's a new requirement?

It is set in /etc/mail/greylist.conf:
user "smmsp"

Cheers.

On Nov 24, 2006, at 9:27 AM, Emmanuel Dreyfus wrote:

> On Fri, Nov 24, 2006 at 05:04:54PM -0000, count_nerdula wrote:
>> For some reason I get warnings about the socket path in
>> /var/milter-greylist being unsafe, using the exact same  
>> configuration,
>> init script, and file/directory ownership as I am using sucessfully
>> for version 3.0.
>>
>> When I switch back to using 3.0, it works just fine.
>
> You forgot --with-user flag to configure?
>
> -- 
> Emmanuel Dreyfus
> manu@...
>
>
>
> Yahoo! Groups Links
>
>
>