Jim Murray wrote:
Chris Babcock wrote:
( Sorry, the first one I sent had some unintended crap in the headers. )
I've been experimenting with the greylisting plugin a bit lately, and
I've noticed some odd behavior.
It seems that mail for domains that aren't in rcpthosts that would
normally get a 5xx message and get rejected are hitting the
greylisting. As a result, they get a 4xx rejection first, and then
after the transition from grey to white, they get a 5xx. I've included
log lines and transcripts below. I'm wondering is this the intended
behavior or should this be counted as a bug?
Do you possibly have the greylisting plugin running before check_relay?
I had similar weirdness on 0.32 and putting greylisting after
check_relay resolved it.
Jim.
A quick dump of the plugins config shows the greylisting plugin after
the check_relay plugin. If I'm reading the code right, check_relay does
the checks but the rejection doesn't happen until the rcpt_ok plugin
runs. So, it looks like the greylisting plugin intervenes before
rcpt_ok throws the "Relaying denied" message.
Also, this host doesn't do any client relaying, so I suspect that if I
allowed a host to relay that functionality would probably work.
------- grep -v "^#\|^$" plugins -------
hosts_allow
dont_require_anglebrackets
check_earlytalker wait 4
check_verybadrcptto
count_unrecognized_commands 4
check_relay
require_resolvable_fromhost
check_badmailfrom
check_badrcptto
check_badrcptto_patterns
check_spamhelo
check_loop
dnsbl
rhsbl
dns_whitelist_soft
sender_permitted_from trust 1 guess 0 spf_deny 0
greylisting remote_ip 1 sender 1 recipient 1 black_timeout 180 mode
denysoft db_dir "$QPHOME/var/db"
auth/authdeny
rcpt_ok
virus/klez_filter
queue/qmail-queue
----------------------------
