Milter-greylist

Hello,

I was wondering why the MX sync was not working at all for me.
I got always the error message in the syslog which is in the subject of this
mail.
Now I found the reason of this bug^H^H^Hfeature.

If a stream is open for update operation between read and write operation
flush operation has to be executed.
"man fdopen" on Tru64 UNIX says among others:

 "Also, an input operation cannot be directly followed by
  an output operation without an intervening flush or file positioning
opera-
  tion, unless the input operation encounters the end of the file."

So I attach now the patch which fixes that problem. I do not know is anybody
else encountered this?

The change from strtok to strtok_r is an artefact of my debugging but I
consider it worthwhile to keep.
It is generally safer to use a re-entrant version of the function in a
thread than the non-re-entrant.
Actually it is not a problem now but it might become later if the code
evolves further.

Bests,
Attila

>So I attach now the patch which fixes that problem.

It seems patch isn't working on Solaris 8. I've applied patch, compilation
was ok, but instead of "Unexpected reply " 200" from peer .." I've seen
"Unexpected reply " add" from peer .."

On Wed, Jun 16, 2004 at 06:49:29PM +0300, Boris Losev wrote:
> It seems patch isn't working on Solaris 8. I've applied patch, compilation
> was ok, but instead of "Unexpected reply " 200" from peer .." I've seen
> "Unexpected reply " add" from peer .."

I suspect this is the same problem at another place: the input buffer and
output buffer get mixed.

-- 
Emmanuel Dreyfus
manu@...

<attila.bruncsak@...> wrote:

> If a stream is open for update operation between read and write operation
> flush operation has to be executed.
> "man fdopen" on Tru64 UNIX says among others:
> 
>  "Also, an input operation cannot be directly followed by
>   an output operation without an intervening flush or file positioning
> opera-
>   tion, unless the input operation encounters the end of the file."

To sum up, we need to fflush after each time data is readen from the
file descriptor, that's it?

-- 
Emmanuel Dreyfus
Il y a 10 sortes de personnes dans le monde: ceux qui comprennent 
le binaire et ceux qui ne le comprennent pas.
manu@...

Boris Losev <Boris.Losev@...> wrote:

> >So I attach now the patch which fixes that problem.
> 
> It seems patch isn't working on Solaris 8. I've applied patch, compilation
> was ok, but instead of "Unexpected reply " 200" from peer .." I've seen
> "Unexpected reply " add" from peer .."

Try adding fflush() before the fgets() in sync.c

-- 
Emmanuel Dreyfus
Il y a 10 sortes de personnes dans le monde: ceux qui comprennent 
le binaire et ceux qui ne le comprennent pas.
manu@...

>The fix is in 1.5.1, so everyone can test if it's okay.

sync is ok (greylist.db on MXes are identical), but "Unexpected reply "add"
from..." still appear in syslog:

Jun 17 11:57:41 intra2 milter-greylist: [ID 829402 mail.info] Incoming MX
sync connexion from 192.168.3.34
Jun 17 12:09:54 intra1 milter-greylist: [ID 699817 mail.info] Connection to
192.168.3.35 established
Jun 17 12:09:54 intra1 milter-greylist: [ID 421412 mail.error] Unexpected
reply "add" from 192.168.3.35, closing connexion (5 entries queued)

Hello,

>>So I attach now the patch which fixes that problem.
>
>It seems patch isn't working on Solaris 8. I've applied patch, compilation
>was ok, but instead of "Unexpected reply " 200" from peer .." I've seen
>"Unexpected reply " add" from peer .."

Now with V1.5.1 I get also the same problem: 'Unexpected reply "add" from
peer...'
The fflush() just after the fgets() in the function sync_server at Solaris 8
produces
the same error than without fflush() at Tru64 UNIX.
If I put there the fflush() the problem just goes away.

Please confirm that the unpatched V1.5.1 working for you fine on Solaris 8?

Bests,
Attila

Hello,

>>The fix is in 1.5.1, so everyone can test if it's okay.
>
>sync is ok (greylist.db on MXes are identical), but "Unexpected reply "add"
>from..." still appear in syslog:
>
>Jun 17 11:57:41 intra2 milter-greylist: [ID 829402 mail.info] Incoming MX
>sync connexion from 192.168.3.34
>Jun 17 12:09:54 intra1 milter-greylist: [ID 699817 mail.info] Connection to
>192.168.3.35 established
>Jun 17 12:09:54 intra1 milter-greylist: [ID 421412 mail.error] Unexpected
>reply "add" from 192.168.3.35, closing connexion (5 entries queued)

To summarize:
1. On V1.5.1 both Tru64 UNIX and Solaris 8 gives the error message:
'Unexpected reply "add" from ...'

This is probably due to the bug when I changed from strtok to strtok_r:
The variable 'cookie' has to be initialized to be NULL:
The "man strtok_r" says among others:
"In the initial call to strtok_r(), the *savept must be the null pointer."


2. On Solaris 8 the MX is working. On Tru64 UNIX the MX is still broken.
There is a need for the fflush() in the sync_server() function after
the fgets() for Tru64 UNIX. I think it does not heart on Solaris 8.

I attach a new diff.

Bests,
Attila