Re: check_recipient_a_access DISCARD leads to 451 4.3.5 Server configuration error

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: check_recipient_a_access DISCARD leads to 451 4.3.5 Server configuration error

@lbutlr
On 14 Nov 2017, at 05:00, flowhosts <[hidden email]> wrote:

> # 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

I hope this bug gets fixed soon, because that looks like it might be super useful with a log monitor and blacklist.

--
Apple broke AppleScripting signatures in Mail.app, so no random signatures.

Reply | Threaded
Open this post in threaded view
|

Re: check_recipient_a_access DISCARD leads to 451 4.3.5 Server configuration error

flowhosts
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:

> On 14 Nov 2017, at 05:00, flowhosts <[hidden email]> wrote:
>> # 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
> I hope this bug gets fixed soon, because that looks like it might be super useful with a log monitor and blacklist.
>

Reply | Threaded
Open this post in threaded view
|

Re: check_recipient_a_access DISCARD leads to 451 4.3.5 Server configuration error

Viktor Dukhovni
On Tue, Nov 14, 2017 at 07:11:03PM +0100, flowhosts wrote:

> 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 :)

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?

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: check_recipient_a_access DISCARD leads to 451 4.3.5 Server configuration error

Noel Jones-2
In reply to this post by flowhosts
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:

> 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:
>> On 14 Nov 2017, at 05:00, flowhosts <[hidden email]> wrote:
>>> # 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
>> I hope this bug gets fixed soon, because that looks like it might
>> be super useful with a log monitor and blacklist.
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: check_recipient_a_access DISCARD leads to 451 4.3.5 Server configuration error

Viktor Dukhovni


> On Nov 14, 2017, at 1:50 PM, Noel Jones <[hidden email]> wrote:
>
> 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.

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...

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: check_recipient_a_access DISCARD leads to 451 4.3.5 Server configuration error

flowhosts
In reply to this post by Viktor Dukhovni
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" <[hidden email]> wrote:
On Tue, Nov 14, 2017 at 07:11:03PM +0100, flowhosts wrote:

> 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 :)

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?

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: check_recipient_a_access DISCARD leads to 451 4.3.5 Server configuration error

Viktor Dukhovni


> On Nov 14, 2017, at 2:02 PM, liquid cooled <[hidden email]> wrote:
>
> 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.

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.

--
--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: check_recipient_a_access DISCARD leads to 451 4.3.5 Server configuration error

Matus UHLAR - fantomas
In reply to this post by flowhosts
On 14.11.17 20:02, liquid cooled wrote:
>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.

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.

--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
How does cat play with mouse? cat /dev/mouse