I guess that the sync_send() function is called after the pending
structure has been updated with the autowhitelist time.
According to pending.h the structure element� struct timeval p_tv is
used to both hold pending time and autowhilist time
struct pending {
������� char *p_addr;
������� struct sockaddr *p_sa;
������� socklen_t p_salen;
������� char *p_from;
������� char *p_rcpt;
������� struct timeval p_tv;��� /* activation time for pending or
tarpitting,
���������������������������������� expiration time for autowhite */
������� struct timeval p_tarpit;/* unsuccessful longest duration for
tarpit */
������� int p_refcnt;���������� /* mutex; pending entry is
���������������������������������� shared with sync queue */
������� tuple_t p_type;�������� /* pending or autowhite entry? */
������� TAILQ_ENTRY(pending) p_list;
������� TAILQ_ENTRY(pending) pb_list;
};
This is very wrong!
Is it possible to get a response from whoever is responsible for the coding?
Best
John
Den 07-06-2018 kl. 20:05 skrev John Damm S�rensen john@...
[milter-greylist]:
>
> I have now collected tcpdump trace illustrating the problem.
>
> When the peer is informed by an autowhitelist instance both times for
> the data and aw argument are the assigned the time that should be the
> aw time.
>
> Since the date has wrong value the peer is unable to locate the tuple
> and update it accordingly.
>
> It is possible to update the autowhitelist manually by telnetting to
> port 5252 on the peer and issue the del2 commands using the date time
> recorded in the db file.
>
> Please fix this problem.
>
> Best
>
> John
>
>
> Den 07-06-2018 kl. 11:16 skrev John Damm S�rensen john@...
> [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