You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
postgreyreport doesn't seem to work with subnet IP lookup. (I haven’t tried with the postgrey --lookup-by-host option enabled.)
The source of the problem seems to be that postgreyreport::do_client_substitutions differs from postgrey::do_client_substitutions. Specifically, the current version of postgrey appends /24 (or whatever the value of ipv4cidr is) to the subnet address, while postgreyreport does not.
As a result, postgreyreport::is_fatal_triplet fails to match the subnet keys in the database and always returns 1.
After several hours of troubleshooting I found this, so thanks for this post. I believe the issue noted here causes no match with the postgrey.db, therefore time difference calculated is always 0. Consequently, the postgreyreport always considers everything a fatal, no matter what the delay is set to.
In case anyone still uses postgreyreport (like myself and I find it extremely useful), editing line 205 and adding the /24/ seems to be a quick but dirty fix. Hopefully the author finds some some time in the future for adjusting this the proper way.
my $subkey = lc "$subnet/24/$sender/$recipient"; # subnet key 1.2.3.0/sender/recipient
postgreyreport
doesn't seem to work with subnet IP lookup. (I haven’t tried with the postgrey--lookup-by-host
option enabled.)The source of the problem seems to be that
postgreyreport::do_client_substitutions
differs frompostgrey::do_client_substitutions
. Specifically, the current version ofpostgrey
appends/24
(or whatever the value ofipv4cidr
is) to the subnet address, whilepostgreyreport
does not.As a result,
postgreyreport::is_fatal_triplet
fails to match the subnet keys in the database and always returns1
.This might be a regression from #25.
The text was updated successfully, but these errors were encountered: