Definitive way to stop misdirected bounces/backscatter

[Trane Francks]

Greetings, all.

Server is blacklisted at backscatterer.org and blocked at Outlook.com/Hotmail/Live.

A look at the mail queue definitively indicated that we were sending misdirected bounces. A spammer would forge a From: address, we'd refuse the mail and bounce it to some poor person at the other end. Enough complaints later and we're stuffed.

There are at least 4 pages of backscatter threads coming up in search and I can't find a DEFINITIVE answer on how to stop backscatter. Can I get help here, please?

WHAT I'VE DONE:
* Enable Greylisting
* Enable RBLs
* Removed Autoresponders from the default package
* Confirmed that Sender Callouts are disabled
* (EDITED TO ADD) Enabled delay for unknown/spam-likely hosts

I removed all the crap from the queue and now I wait. Is there anything further that needs to be done to ensure forged From: addresses don't have us bouncing spam?

Not looking for a long conversation. There are 4 pages of threads on the topic that haven't really been helpful. In 2019, this stuff is just getting worse and worse. Need the full recipe to keep things legit.

Thanks, gang.

trane

 

[sparek-3]

If you are accepting messages and then bouncing them, then that's your problem. Don't do that.

This is also why you can't use Fail in Filters - because the Filtering logic doesn't take place until the server has already accepted the message. But I've tried to explain to this to cPanel for years... and I finally just gave up.

If you accept a message, if you actually queue the message in your mail queue, then you either need to deliver it or silently discard it. Bouncing it after you accept it is going to create problems.

This is also why forwarding mail off of the server is a bad idea. Because you really can't know if the server the forwarder is sending the message to is going to accept the message and you've already accepted it to your server.

 

[Trane Francks]

"Not looking for a long conversation."

It's helpful to be RFC-compliant, so blackhole isn't an option. Either read the post again and answer in accordance with the requested information or just don't reply. Thanks for playing.

As for forwarding, we agree. It's a feature I'd rather not offer.

 

[Trane Francks]

I just enabled SpamAssassin globally and enabled "Do not forward mail to external recipients if it matches the Apache SpamAssassin™ internal spam_score setting".

 

[cPanelLauren]

This is also why you can't use Fail in Filters - because the Filtering logic doesn't take place until the server has already accepted the message. But I've tried to explain to this to cPanel for years... and I finally just gave up.

If you accept a message, if you actually queue the message in your mail queue, then you either need to deliver it or silently discard it. Bouncing it after you accept it is going to create problems.

RFC compliance is why this isn't done automatically - we offer the option for blackhole but it's definitely not RFC compliant and most users want this. The filtering logic takes place as when exim accepts a message while going through a series of ACL's/Checks.

I just enabled SpamAssassin globally and enabled "Do not forward mail to external recipients if it matches the Apache SpamAssassin™ internal spam_score setting".

If the mail isn't being sent via a forwarder this probably isn't going to help this issue. Unfortunately, in order to remain RFC compliant you need to bounce the mail, without blackholing mail like this I don't really see another option.

 

[sparek-3]

RFC compliance is why this isn't done automatically - we offer the option for blackhole but it's definitely not RFC compliant and most users want this. The filtering logic takes place as when exim accepts a message while going through a series of ACL's/Checks.

Are you sure about that? Maybe you've changed things since I last gave this a long look... I don't really know how you would be doing this.

Filtering was always done on messages AFTER it was accepted by the server (i.e. given an exim message id). It is only at that point that filters are processed and message are determined to have hit or missed on the filters. With that being the case, you can't fail messages at this stage, because this going to result in a backlog of "bounce" messages trying to be sent out to non-existant email addresses.

Now if you are talking about :fail: in /etc/valiases... yes this is done before the message is accepting. This is fine.

But I'm talking about filters. /etc/vfilters or /home/<user>/etc/filters (I'm too lazy to look up the exact location for this right now).

Try it.

Set up a filter such that if the subject contains "oogly boogly" then fail that message.

Then send a message from [email protected] with the subject "oogly boogly".

Exim will accept the message AND THEN find out that it can't deliver the message because it matches a filter and then it will try to "bounce" the message back to [email protected] which will get stuck in your queue.

 

[cPanelLauren]

These are excerpts from running a fake transaction with exim in debug:


This is an account level filter:

file check: +${extract{5}{:}{${lookup passwd{${lookup{$domain}lsearch{/etc/userdomains}{$value}}}{$value}}}}/etc/$domain/$local_part/filter
expanded file: /home/$user/etc/domain.us/$user/filter
stat() yielded -1
errno = 2
virtual_user_filter router skipped: file check

This is a global filter

rda_interpret (file): /etc/vfilters/${domain}
expanded: /etc/vfilters/domain.us
search_tidyup called
changed uid/gid: central_filter router (recipient is [email protected])
  uid=1000 gid=1002 pid=6258
  auxiliary group list: <none>
turned off address rewrite logging (not root or exim in this process)
709 bytes read from /etc/vfilters/domain.us
data is an Exim filter program
Filter: start of processing
Filter: end of processing
search_tidyup called
rda_interpret: subprocess yield=1 error=NULL
central_filter router declined for [email protected]

All of these are routers and part of the process that occurs every time a message is submitted for acceptance and hasn't changed in a very very long time (if ever) as far as I am aware.

Exim will accept the message AND THEN find out that it can't deliver the message because it matches a filter and then it will try to "bounce" the message back to [email protected] which will get stuck in your queue.

If you've set the filter to fail or fail with a message then yes this will occur - if you set it to blackhole/discard this shouldn't occur

 

[sparek-3]

If you've set the filter to fail or fail with a message then yes this will occur - if you set it to blackhole/discard this shouldn't occur

I guess the question becomes... why is fail an option for filters then?

Either my own tests (which I just did after I made this post and it operates as I wrote/expected) aren't jiving with your own tests or I'm not explaining something well enough.

...

At any rate, this is not an issue for me. I remove the option to set messages to fail in filters by directly modifying the paper_lantern theme on each cPanel update - so my users don't even see Fail as an option in their cPanel. I've tried to explain this issue on various forum posts throughout the years, never got any traction (again either my tests are operating differently or I'm not fully explaining something) so I just took matters into my own hands and did what I thought was best for my servers.

 

[PeteS]

I have the same issue as Trane. Backscatter listed my IP.

I don't see any logical way to defeat this, other than NOT sending any bounces, am I wrong...?

If email comes in to a non existent address, and has a valid formatted sender/replyto then the bounce will go there (as it theoretically should). The only option is if it was detected that the sending server is un-trusted, but that applies to all incoming mail, and wouldn't we love to be able to block all the SPAM, especially to existing addresses?

Backscatter suggests that it should be simple to find the offending actions in the logs (oh really?), and then states that this comes as a result of mis-configured mail servers (oh really?)

Feel free to correct me, and provide the *definitive* solution.

-Pete

 

[sparek-3]

If email comes in to a non existent address, and has a valid formatted sender/replyto then the bounce will go there (as it theoretically should). The only option is if it was detected that the sending server is un-trusted, but that applies to all incoming mail, and wouldn't we love to be able to block all the SPAM, especially to existing addresses?

That appears to be the confusion to what constitutes a "bounce" within this discussion.

If a spammer from ServerA tries to send an email an email address on your domain on ServerB - if that email address does not exist and if you have your unrouteable address (a lot of times called the default address ... but the naming of this address is another point of contention) set to fail. Then ServerB never accepts it. ServerB never sends anything back, it just doesn't accept the message. It's then up to ServerA to send the "bounce" message back to the original envelope-sender.

This is proper. Because if ServerA is sending out spam, then ServerA needs to be the one to deal with it.

In this scenario your server - ServerB - is doing nothing wrong.



The problem becomes if your server - ServerB - accepts this message AND THEN decides that "hey I don't want to deliver this message", THEN your server - ServerB - will be trying to send the bounce message back to the original envelope-sender.

If your server accepts a message - if exim gives it a message id - then you either need to deliver it to the intended recipient or blackhole (pipe it to /dev/null) it.

 

[PeteS]

The problem becomes if your server - ServerB - accepts this message AND THEN decides that "hey I don't want to deliver this message", THEN your server - ServerB - will be trying to send the bounce message back to the original envelope-sender.

If your server accepts a message - if exim gives it a message id - then you either need to deliver it to the intended recipient or blackhole (pipe it to /dev/null) it.

Ok, well said. So in short, using your scenario: Bounces are informed from ServerB to ServerA, and ServerA sends the bounce, but ServerB should never send bounces to senders that sent through ServerA. I am not finding these in logs at the time Backscatter says the offense took place. No doubt I am not looking for the correct thing. Any suggestions about how this would look in an Exim log from a cPanel server? What would cause these incorrect bounce emails on a "stock" cPanel server?

Am I correct that it might also be other emails replying to a forged sender address? Thus the discussion of autoresponders, I assume this would be a user that set up a filter that uses "fail with message" that goes back to the faked sender.

Re: blackholing It seems that wouldn't be a party foul if the received message is deemed unwanted within the system (by a SPAM filter, or a user action/filter).

The more I think on this, the worse it gets! Back to the OP's post: is there not a specific way to detect these offending email and stop them I'd love some answers.

-Pete

 

[sparek-3]

It's going to be difficult to advise you exactly on what to do for your situation without have clear and precise examples. And this really isn't the venue for publicly posting such information.

What is making you believe that your server - ServerB - is sending bounce messages?

You would need to find the exim message id for one of those messages and then search through your exim_mainlogs for that message id to figure out exactly what is happening with it.

If your server is accepting messages for email accounts that do not exist... that would seem to be a configuration issue some where.

If the email account is not listed in /home/<cpaneluser>/etc/<domain>/passwd or /etc/valiases/<domain> but it's being accepted any way... that's something that needs to be investigated.

 

[PeteS]

Because backscatterer.org says so... *eyeroll* "You will either find that your system tried to send misdirected bounces or misdirected autoresponders to claimed but in reality faked senders, or your system tried sender verify callouts against our members near that time."

I won't pay any ransoms, but I would sure appreciate if they gave even one example to go on. The time alone is still pretty vague because of the amount of traffic. Thank you for you comments, they have helped me gett started thinking this through.

cPanel: It's not like this is a new issue, and it seems to me that you would have this better documented. E.G. Look for "this" in logs, do "this" about it; "these are the risks and benefits" of all settings that can affect this issue. Hmmm?

-Pete

 

[Trane Francks]

We legitimately had misdirected bounces frozen in the queue. The process I outlined earlier in the thread resolved all our problems. It basically boils down to:

* Use Greylisting
* Use the cPanel RBLs
* Enable SpamAssassin globally
* Do not forward any mail that SpamAssassin determines is spam
* Work with clients to reduce off-server forwarders (our clients were cooperative! )
* Don't use VRFY (it's disabled in cPanel by default)
* BONUS: Remove autoresponders from the default package

Since enabling this, we've literally only had 9 mails get frozen in the queue. All were addressed for off-server forwarders and all were correctly marked/frozen as spam. I deleted them. Since making all these changes, no further triggers have been logged at backscatterer.org. I'm a happy boy.

 

[sparek-3]

Well... to me, backscatter is more of a symbol that you are doing something wrong (maybe wrong is too strong of a word... ill-advised)

Backscatter is going to happen for 3 main reasons:

• You have a filter set up and set to fail the message

• You have a forwarder setup that is malfunctioning in some capacity. Autoresponders also fit in here.

• You have an improperly configured contact form or script that is sending mail.


Filters that fail are probably the best example of what real backscatter is. But this is just an improper behavior. A mail server cannot accept a message and then decide to bounce it without expecting to get caught up in backscatter. I really have no idea why cPanel has this as an option... beats me!

Forwarding mail off a server (to a server that you have no control of) and using autoresponders are just a really bad idea. Unfortunately you can't stop it completely. But the more unchecked mail you forward off of the server the more issues you are going to have. If you're going to forward mail off of the server, then you really need to have some type of spam checking done BEFORE your server accepts the message. Now I don't know how cPanel's "Do not forward any mail that SpamAssassin determines is spam" function works. If cPanel is accepting the message AND THEN scanning it for spam and rejecting it... then you're back to the fail in filter scenario in the above paragraph. I developed a system a long time ago that grabs a list of email addresses that forward off of the server and forces a spam check of any message sent to any of those addresses BEFORE exim accepts the message. This helps quite a bit. But still if a message passes this spam test, gets accepted by my server, and then Hotmail or where ever the message is ultimately going rejects the message, this can generate backscatter.

Autoresponders also fit in here, perhaps a bit more because autoresponders - by nature - are suppose to automatically respond. If someone sends an email from a non-existant email address to an email address with an autoresponder, then that autoresponder is going to generate backscatter because it will never be able to send the autoresponder message back to the non-existant email address.

The bottom-line here... if the whole world would stop forwarding mail off of the server (intra-server forwarding - forwarding to email accounts within the same server - is fine, because you can ultimately control email accounts there) this would go a long ways towards solving this issue.

Improperly configured contact forms or scripts. A lot of times we see users who keep a default email address set as the envelope-sender within their script or contact form - i.e. [email protected] - this may work fine as long as the person submitting the contact form uses a real email address. But when bots, spammers, or just abusive users use that form and don't put in a real, proper email address, then this causes the server to attempt to send a bounce message to [email protected] This is solved (I use the term loosely) by informing the website owner that their script is misconfigured. [email protected] needs to be their real email address.

Another issue we see with contact forms and scripts... people may write the script in such a way that the message is sent "from" whatever email address the submitter puts on the form. This is fine for the From header... but the envelope-sender needs to be set to a real, known to be good, email address. The envelope-sender is where bounce messages are going to be sent from. If the creator of the script writes the script so that the envelope-sender is dynamically set based on the user's input, then if the To address is not configured properly (see above paragraph) then the bounce message may go to a non-existant email account... backscatter.

So the only way to really solve all of this is through end-user education. Why are users forwarding mail off of the server? Why are they not just advertising their Gmail account and instructing users to send there? The more hoops you add (adding forwarders) to the process, the greater your surface area for issues. If you're using an autoresponder, why? These days, everyone checks their mail on their phone anyway - is a message telling everyone that you are on vacation really necessary? If a user is not properly configuring their scripts... nothing is going to solve that except for fixing the configuration of the script (which I'd be willing to bet was in the documentation for setting it up, but was conveniently overlooked).

RBLs will function a lot like a global SpamAssassin. If a connecting IP coming into your mail server matches one of the RBLs, then the connection is denied. Exim never gets to accept the message. This will help a lot too.

To the point about silently discarding message in filters... I would tend to agree, I don't like that option either. I always try to advise users to move those messages out into another folder and then review that folder from time to time. If you discard a message automatically... you'll never know that it was discarded. So if someone is complaining that they wrote you an email and you never got it... check your filters. If that person uses any word or language that you have set to filter... the filters are unbiased, they don't care if you know the person that is sending you the message or not... if it matches something in the filter, it's going to act on that filter. And if the action on that filter is to delete it... it's gone and you and the sender are none the wiser.

 

[Trane Francks]

Past tense: Was doing something wrong. As stated in my last post, my situation is resolved and I'm delighted at the outcome. I've no further need to monitor this thread.

 

[Steve Kemp]

Im having ongoing issues with Backscatterer on one server and im a bit puzzled as to how to best deal with it

miss directed bounces seem to be the issue

Im running Mailscanner on the server and i tried as a test to add an exim filter to not send bounces:

if $sender_address is ""
then
if ${lookup{${extract{2}{@}{$recipients}}}lsearch{/etc/localdomains}{yes}{no}} is "no"
then
fail text "Delayed bounce message ignored"
seen finish
endif
endif

I was hoping this would stop a lot of the bounce messages going out but it did not work

if there a more definitive way of stopping these stupid miss directed bounces?

 

[Takito]

I have this problem for a long time, I have tried to contact backscatterer.org asking to post a solution for cPanel servers and got no response.
Also I have chosen to use "Initial default/catch-all forwarder destination - Blackhole" and it doesn't help!

 

[keat63]

Could I just ask.

In the end user cpanel, under the email account is the ability to suspend receiving of email.
Would this create a bounce ?

 

[cPanelLauren]

It does create a bounce:

Your message wasn't delivered to [email protected] because the address couldn't be found, or is unable to receive mail.