Also check in sync.c:
#define SYNC_PROTO_CURRENT 3
On my system the sequence of commands sent to the peer are:
vers3
del2 addr <IP> from <mail address> rcpt <mail address> date <date in
seconds> aw <same as date argument>
I also notice that the milter keeps the connection to the peers over
time. Verified with netstat -an | grep 5252.
So please check that the connections are not dropped.
Best
John
Den 06-06-2018 kl. 11:07 skrev John Damm S�rensen john@...
[milter-greylist]:
>
> Somewhat confusing the man page for the config file says that peer
> entries for the local host wil be ignored, which by the way also seems
> more reasonable.
>
> �� peer 192.0.2.18
> �������� peer 192.0.2.17
> �������� peer 192.0.2.22 timeout 7
> �������� peer 192.0.2.38 timeout 5m
>
> ������ You can list the local machine in the peer statements, it will
> be ignored.
>
>
> Best
>
> John
>
>
> Den 06-06-2018 kl. 10:58 skrev John Damm S�rensen john@...
> [milter-greylist]:
>>
>> I don't know whether this matters. But one thing that crosses my mind
>> is that it seems like you have all peers defined on all hosts.
>>
>> According to the man page you should leave out the local machine as
>> it would otherwise talk to itself and make duplicate entries in the
>> dump file.
>>
>> Another thing is that the AW functionality only works with version 2
>> servers. Try to telnet to port 5252 on all four servers and type
>> vers2 and notice the response.
>>
>> telnet server2 5252
>> help
>> 203 Help? Sure, we have help here:
>> 203
>> 203 Available commands are:
>> 203 help� -- displays this message
>> 203 quit� -- terminate connection
>> 203 vers2 -- speak version 2 protocol
>> 203 vers3 -- speak version 3 protocol
>> 203 add addr <ip> from <email> rcpt <email> date <time>� -- add en entry
>> 203 del addr <ip> from <email> rcpt <email> date <time>� -- remove en
>> entry
>> 203 del2 addr <ip> from <email> rcpt <email> date <time> aw <time> --
>> remove en entry, adding it to autowhite with given delay (version 2 only)
>> 203 flush addr <ip> -- remove anything about an ip� (version 3 only)
>>
>> Cheers
>> John
>>
>> Den 26-05-2018 kl. 20:53 skrev Gienek Nowacki gieneknowacki@...
>> [milter-greylist]:
>>> Hi,
>>>
>>> I've got four MX servers and observed strange behavior of
>>> milter-greylist.
>>> Please, see the fragments of databases (dumpfiles) below of each
>>> servers:
>>>
>>> # server1
>>> 1.2.3.4 <sender@... <mailto:sender@...>>
>>> <recipient@... <mailto:recipient@...>>
>>> 1527324170 # 2018-05-26 10:42:50
>>>
>>> # server2
>>> 1.2.3.4 <sender@... <mailto:sender@...>>
>>> <recipient@... <mailto:recipient@...>>
>>> 1528536443 AUTO # 2018-06-09 11:27:23
>>>
>>> # server3
>>> 1.2.3.4 <sender@... <mailto:sender@...>>
>>> <recipient@... <mailto:recipient@...>>
>>> 1527324170 # 2018-05-26 10:42:50
>>>
>>> # server4
>>> 1.2.3.4 <sender@... <mailto:sender@...>>
>>> <recipient@... <mailto:recipient@...>>
>>> 1527324170 # 2018-05-26 10:42:50
>>>
>>> It shows, that serwer2 recived the email and milter-greylist added
>>> the flag AUTO.
>>>
>>> After the time of 8 hours (because of timeout=8h), this information
>>> contains server2 only:
>>>
>>> # server2
>>> 1.2.3.4 <sender@... <mailto:sender@...>>
>>> <recipient@... <mailto:recipient@...>>
>>> 1528536443 AUTO # 2018-06-09 11:27:23
>>>
>>> So, at this situation, when the sender will start sending second
>>> email (the parameters: IP, sender, recipient are still the same) and
>>> connects to server3 or serwer1, or server4 it will be wait.
>>>
>>> From my point of view, waiting in such situation is a nonsens.
>>>
>>> Why the information abut 'autowithe' isn't distributed over all MX
>>> servers?
>>>
>>>
>>> P.S
>>> All my config files are as follow:
>>>
>>> stat "|logger -p mail.info"� "milter-greylist: MILTERSTAT:
>>> %T{%Y.%m.%d %T} %d [%i] %f -> %r %S (ACL %A) %Xc %Xe %Xm %Xh\n"
>>> geoipdb "/usr/share/GeoIP/GeoIP.dat"
>>> verbose
>>> peer 10.10.10.1
>>> peer 10.10.20.2
>>> peer 10.10.30.3
>>> peer 10.10.40.4
>>> syncaddr * port 5252
>>> racl whitelist addr 127.0.0.0/8
>>> racl whitelist addr 10.0.0.0/8
>>> racl whitelist addr 172.16.0.0/12
>>> racl whitelist addr 192.168.0.0/16
>>> report all
>>> delayedreject
>>> dumpfreq 5m
>>> timeout 8h
>>> greylist 6m
>>> autowhite 14d
>>> subnetmatch /24
>>> nodrac
>>> quiet
>>> pidfile "/var/run/milter-greylist.pid"
>>> socket "/var/spool/postfix/milter-greylist/milter-greylist.sock" 666
>>> dumpfile "/var/spool/postfix/milter-greylist/greylist.db" 600
>>> user "postfix"
>>> racl whitelist spf pass
>>> racl greylist spf fail� msg "SPFINFO: SPF:f Greylisting in action:
>>> host %d [%i]� domain '%sf'" delay 60m autowhite 14d
>>> racl greylist spf error msg "SPFINFO: SPF:e Greylisting in action:
>>> host %d [%i]� domain '%sf'" delay 60m autowhite 14d
>>>
>>> Regards,
>>> Gienek Nowacki
>>>
>>>
>>
>>
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>> Virusfri. www.avast.com
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>>
>>
>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
>
---
Denne e-mail blev kontrolleret for virusser af Avast antivirussoftware.
https://www.avast.com/antivirusMessage
Re: [milter-greylist] Why autowhite isn't distributed over all MX?
2018-06-06 by John_Damm_S=c3=b8rensen
Attachments
- No local attachments were found for this message.