Thats totally true,
i i have to deal with listings of my ip addresses on blacklists very often. Yes the hops which are affected here are: Sieve generates the forwarded mail, one of the postfix mta-out hosts tries to deliver it and fails generating the Mailer-Daemon which also fails to get delivered, then it gets passed on to my postfix fallback mta-out where check_recipient_a_access happens. joe-job forgery sounds interesting i will give this a read! To let the user choose the scenario is definatly an way/option i can imagine. Thanks a lot for your input Victor i will look into making my mailsystem to a more friendly place for other mail hosts (and me). Am 14/11/2017 um 20:18 schrieb Viktor Dukhovni:
On Nov 14, 2017, at 2:02 PM, liquid cooled <flowho...@gmail.com> 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.
