DevHeads.net

check_recipient_a_access DISCARD leads to 451 4.3.5 Server configuration error

Hello,

as described in the subject i tried to implement the new feature
check_recipient_a_access
I have encountered a strange error or maybe an bug.

The following settings result in an correct action follwed by an "4.3.5
Server configuration error" response.
# main.cf
smtpd_recipient_restrictions =
        reject_non_fqdn_sender
        ...
        check_recipient_a_access
hash:/etc/postfix/lookup/recipient_a_access
        ...
        permit

# cat /etc/postfix/lookup/recipient_a_access
185.140.110.3 DISCARD

# maillog
Nov 14 10:53:54 fallback postfix/smtpd[7187]: NOQUEUE: discard: RCPT
from unknown[192.168.xxx.xxx]:53698:
< ... at netgooya dot com>: Recipient address triggers
DISCARD action; from=<> to=< ... at netgooya dot com>
proto=ESMTP helo=<bsmtp.xxx.xx>
Nov 14 10:53:54 fallback postfix/smtpd[7187]: warning: restriction
check_recipient_a_access returns OK for <a href="mailto: ... at netgooya dot com"> ... at netgooya dot com</a>
Nov 14 10:53:54 fallback postfix/smtpd[7187]: warning: this is not
allowed for security reasons
Nov 14 10:53:54 fallback postfix/smtpd[7187]: warning: use DUNNO instead
of OK if you want to make an exception
Nov 14 10:53:54 fallback postfix/smtpd[7187]: NOQUEUE: reject: RCPT from
unknown[192.168.xxx.xxx]:53698: 451 4.3.5 Server configuration error;
from=<> to=< ... at netgooya dot com> proto=ESMTP
helo=<bsmtp.xxx.xx>
Nov 14 10:53:54 fallback postfix/cleanup[7844]: 3ybjWk29Jhz5vXS:
message-id=< ... at smtp dot xxx.xx>

If DISCARD is replaced by HOLD in "recipient_a_access" the error won't
appear but in fact the sending host also receives an OK message like it
does above when discarding the mail, which should not be allowed if you
trust the warning message received.

So is this a bug when using DISCARD or is it the right behaviour?
And if it's not a bug then i think HOLD is buggy because it does not
respond with an "451 4.3.5 Server configuration error".

Where can i file a bug report?
Or can someone confirm this behaviour?

Thanks in advance,
Patrick

Comments

PATCH: check_recipient_a_access DISCARD leads to 451 4.3.5 Serve

By Wietse Venema at 11/16/2017 - 11:38

This patch applies to Postfix 3.0 and later.

Wietse

--- ./src/smtpd/smtpd_check.c- 2017-05-31 16:29:46.000000000 -0500
+++ ./src/smtpd/smtpd_check.c 2017-11-16 09:32:46.898378490 -0600
@@ -4044,7 +4044,7 @@
static void forbid_whitelist(SMTPD_STATE *state, const char *name,
int status, const char *target)
{
- if (status == SMTPD_CHECK_OK) {
+ if (state->discard == 0 && status == SMTPD_CHECK_OK) {
msg_warn("restriction %s returns OK for %s", name, target);
msg_warn("this is not allowed for security reasons");
msg_warn("use DUNNO instead of OK if you want to make an exception");

Re: check_recipient_a_access DISCARD leads to 451 4.3.5 Server c

By LuKreme at 11/14/2017 - 13:52

On 14 Nov 2017, at 05:00, flowhosts < ... at gmail dot com> wrote:
I hope this bug gets fixed soon, because that looks like it might be super useful with a log monitor and blacklist.

Re: check_recipient_a_access DISCARD leads to 451 4.3.5 Server c

By flowhosts at 11/14/2017 - 14:11

Yes this is such a decent feature!
I use it with the hold action now as this doesn't break things.
So bad domains (in my case) which would never accept mails are now kept
in place, i call it the bad destination hold quarantine.
Looking forward to massive discarding soon :)

@Noel Jones, thanks!

Am 14/11/2017 um 18:52 schrieb @lbutlr:

Re: check_recipient_a_access DISCARD leads to 451 4.3.5 Server c

By Noel Jones at 11/14/2017 - 14:50

Usually (almost always) REJECT is a more appropriate action for
unwanted mail. Is there some reason you can't use REJECT until this
is fixed?

I guess you're using this to trap mail your users send to bad/typo
domains eg. hotmal.com? In that case, REJECT would be better to
notify the user of their mistake.

-- Noel Jones

On 11/14/2017 12:11 PM, flowhosts wrote:

Re: check_recipient_a_access DISCARD leads to 451 4.3.5 Server c

By Viktor Dukhovni at 11/14/2017 - 15:01

The effect is of course different for multi-recipient mail.
With DISCARD no recipients get the ail, with REJECT only
the "bad" recipients don't get the mail. If one of the
"good" recipients then uses "Reply-All" the "bad" recipient
might still see the message.

And yet I am still puzzled what the use-case is for
DISCARD in check_recipient_a_access... I hope the
OP is willing to elaborate on what real-world problem
that solves...

Re: check_recipient_a_access DISCARD leads to 451 4.3.5 Server c

By Viktor Dukhovni at 11/14/2017 - 14:19

While DISCARD is clearly not behaving as expected here, I am puzzled
as to when you might want the expected behaviour. Is this a
submission service, and you're trying to discard mail from compromised
accounts? What is the use-case for discarding a message one of
whose recipients has a domain whose MX hosts match some IP address?

Re: check_recipient_a_access DISCARD leads to 451 4.3.5 Server c

By flowhosts at 11/14/2017 - 15:02

The problem is as follows:
A spammer is using an ip address which hast thousands of domains
registered, the apammer uses a botnet to send from his domains but from
many different source ips.
My customers then receive the spams and a lot of them have forward anything
rules, the new generated forwarded mails could be rejected by the receiving
mailhosts through lets say any spamhaus rbl, my mtaout hosts then forge
mailer daemon mails for the originating source domains which all lead to
the same ip which does not run a mail service, my fallback hosts then fill
up with this mailer daemon messages.

So another point is im not allowed to use intransparent mail blocking like
rbl lists, or oher spam detecting systems, the only thing i use is an user
configurable spam / virus detection service. So if a user wants spam he
gets it... And if he forwards it i get into the described dilemma.

I operate a pretty large mail system so i had about 100k of these mailer
daemons per day or even more.

For about 3 weeks i got a cronjob running which postsupered the mailer
daemon mails hourly, until i discovered the postfix recipient_a_access
feature.

Hope that clears things up!

On 14 Nov 2017 7:20 p.m., "Viktor Dukhovni" <postfix- ... at dukhovni dot org>
wrote:

Re: check_recipient_a_access DISCARD leads to 451 4.3.5 Server c

By Matus UHLAR - f... at 11/15/2017 - 14:10

On 14.11.17 20:02, liquid cooled wrote:
don't you want to use check_sender_a_access instead?
last time we received spame from that kind of abusers, I configured that
one.

Re: check_recipient_a_access DISCARD leads to 451 4.3.5 Server c

By Viktor Dukhovni at 11/14/2017 - 15:18

I see, so you're obligated to accept mail that downstream hosts your
users forward to often reject, and then you become a backscatter source,
but some of the backscatter clogs your queue, so you've found a way to
discard it (there must an SMTP hop between the place where the bounce
is generated and the systems that would otherwise queue this mail).

Can't say I'm entirely sympathetic, as lots of other backscatter, that
is not clogging your queue, is still going out, perhaps to various victims
of joe-job forgery. Doing forwarding without filtering imposes externalities
(costs) on others and is perhaps not a socially responsible thing to do.
Ideally your users would only be able to choose at most one of:

* Opt out of email filtering via RBLs and anti-spam content filters
* Enable forwarding to an external mailbox

If they want forwarding, they'd have to accept filtering.

Note that since bounces have a single recipient, REJECT is as effective
as DISCARD here.

Re: check_recipient_a_access DISCARD leads to 451 4.3.5 Server c

By Noel Jones at 11/14/2017 - 12:17

On 11/14/2017 6:00 AM, flowhosts wrote:

Confirmed (on postfix 3.2-20160730, using an inline: map).

This looks like a bug, consider it reported. Thanks for finding this.

-- Noel Jones