Bugzilla Bug 102769

if the MXGREY-Option ist set to 1 in gld.conf
the mail is accepted if the "rcpt to:"-Line in smtp-chat is given three ore more
time regardless of the time elapsed since the first time
any minimal timeout between first and succesful try is ignored

Reproducible: Always
Steps to Reproduce:
1.connect to an gld-proteced postfix with activated MXGREY
2.send a mail that get greylisted
3.retry for three times within the minimal timemout

Actual Results:  
the mail is accepted at the third try,
even if the minimal timeout has not elapsed

Expected Results:  
the mail should have been delayed untiul the timeout elapsed

Portage 2.0.51.22-r2 (default-linux/x86/2005.0/2.4, gcc-3.3.5, glibc-2.3.5-r0,
2.4.32-pre1-it4linux i686)
=================================================================
System uname: 2.4.32-pre1-it4linux i686 AMD Athlon(tm) Processor
Gentoo Base System version 1.6.13
distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled]
dev-lang/python:     2.3.5
sys-apps/sandbox:    1.2.10
sys-devel/autoconf:  2.13, 2.59-r6
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5
sys-devel/binutils:  2.15.92.0.2-r10
sys-devel/libtool:   1.5.18-r1
virtual/os-headers:  2.4.30-r1
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O3 -mcpu=athlon-tbird -march=athlon -fomit-frame-pointer -ffast-math
-pipe "
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config
/usr/lib/X11/xkb /usr/lib/fax /usr/share/config /usr/share/texmf/dvipdfm/config/
/usr/share/texmf
/dvips/config/ /usr/share/texmf/tex/generic/config/
/usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/bind
/var/qmail/control /var/spool/fax/etc"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O3 -mcpu=athlon-tbird -march=athlon -fomit-frame-pointer -ffast-math
-pipe "
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks sandbox sfperms strict"
GENTOO_MIRRORS="http://funtaskic.informatik.uni-bremen.de/ftp/gentoo/"
LANG="de_DE@euro"
LC_ALL="de_DE@euro"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/etc/portage/overlay"
SYNC="rsync://rsync.linux-net.dnsalias.net/gentoo-portage/"
USE="3dnow 3dnowex 3dnowext X acl acpi alsa apm arts avi berkdb bitmap-fonts
bzlib cdr crypt curl dvd emboss encode esd fam foomaticdb fortran gd gdbm gif
gtk gtk2 im
agemagick imlib java jpeg libg++ libwww mad mikmod mmx motif mp3 mpeg mysql
ncurses nls ogg oggvorbis oss pam pdflib perl png python qt quicktime readline
samba sdl s
pell ssl tcltk tcpd tetex tiff truetype truetype-fonts type1-fonts vorbis x86
xml2 xmms xv zlib userland_GNU kernel_linux elibc_glibc"
Unset:  ASFLAGS, CTARGET, LDFLAGS, LINGUAS

backgronud informations and implementation details:

gld use a timestamp OR a try counter for making its decision 
when MXGREY is switched off 
every server,sender,receipent triple get delayed until the timeout calculated
from  the first attempt elapsed, but the attempt counter get increased, altough
the mail is further delayed

when MXGREY is switched on 
an additional check is done if the server has a try-counter set to more than one

in fact this means that the timeout has to be elapsed OR the try-counter has to
reach 2, as simply specifying the receipient three times fullfills the last
condition, every (specially crafted) mail can pass within the first connection
and a single second

Created an attachment (id=66109) [edit]
gld-1.5.2-mxgrey-fix.patch.bz2

this patch changes the SQL-database-update behavior, so that the try counter is
only increased when the minimal timeout is elapsed.

so the counter will stay at one until the timeout is elapsed and therefor
MXGREY will NOT accept the mails to

the latest-try-timestamp is still upgraded, as it is not used by the
greylisting-algorithm

by now I can add that the patch works well

and has the additional advantage, that the counter stays at one, so unsuccessful
tries can be identified more easy ...

Fixed in CVS, thanks.