Milter-greylist

Further testing seems to be realted to the fact that the date aw times 
sent to the peers are equal. This apparently tricks the peer to delete 
the entry.

I tried to del2 an existing entry in teh db but with different data and 
aw times, and this time the AUTO whitelist was added to the db.

Would somebody please investigate why the time for date and aw is used?

Best

John


Den 06-06-2018 kl. 20:17 skrev John Damm S�rensen john@... 
[milter-greylist]:
>
> Well I did some testing on my systems and indeed it seems like the 
> autowhite information is not recorded by the peer.
>
> Instead when the del2 command is issued the entry is removed.
>
> So there must be a problem in the way the pending list is updated 
> failing to change from pending type to autowhitelist. As can been seen 
> from the snippet that controls what to write to the db file.
>
> if (conf.c_dump_no_time_translation) {
> ����������������������� if (pending->p_type == T_AUTOWHITE) {
> ������������������������������� fprintf(stream, "%s\t%s\t%s\t%ld AUTO\n",
> ����������������������������������� pending->p_addr, pending->p_from,
> ����������������������������������� pending->p_rcpt,
> (long)pending->p_tv.tv_sec);
> ����������������������� } else if (pending->p_type == T_PENDING) {
> ������������������������������� fprintf(stream, "%s\t%s\t%s\t%ld \n",
> ����������������������������������� pending->p_addr, pending->p_from,
> ����������������������������������� pending->p_rcpt,
> (long)pending->p_tv.tv_sec);
>
> 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/antivirus