Ed McLain wrote:
Been having some issues where a connection would be killed by DENY or
DENYSOFT in the rcpto stage and yet qpsmtpd would allow the sender to
continue issuing commands and still accept the email.  I've thrown together
a quick little patch that implements a {_killed} variable based on the code
to $self->respond.  If the code is 4xx or 5xx then _killed gets set and no
other commands are taken by read_input except for quit.  It's working here
just fine it seems but if anybody has any problems or comments with it let
me know.  The diff is against svn 790.

I can't speak for everyone, but this is the reason why some people use DENY_DISCONNECT instead for the gatekeeper plugins; badly behaved MTA's (read that as zombie spawn) don't pay attention to return codes and just keep spewing their crap. I just recently changed dnsbl to include the 'action disconnect' configuration, because the servers blocked via zen were just hanging onto the socket until the 20 minutes were up.

In addition, your solution is wrong to fire in the TO stage, since the RFC's specifically a permit a per-user temporary or permanent error. Think of a situation where a single message is targeted to two users: UserGood (who keeps her Inbox clean) and UserBad (who keeps every single fricken message that he has ever been sent). If UserBad is overquota, qpsmtpd can send a 4XX error and still accept the message for UserGood. With your patch, no message gets delivered.

John

Reply via email to