backscatter

[keat63]

I've seen a few posts describing backscatter and the fact it could end up getting you blacklisted.

Lets assumea spammer sends 1000's of emails to: some_name_that_doesnt.exist.com
Could 'exist.com' end up blacklisted through back scatter, due to :

rejected RCPT <some_name_that_doesnt.exist.com>: No such person at this address.

 

[cPanelLauren]

Backscatter is typically misdirected bounces. If you're getting that error:

rejected RCPT <some_name_that_doesnt.exist.com>: No such person at this address.

Typically this is handled at SMTP time so that wouldn't be something that would be included in backscatter. There is a huge difference in Reject and Bounce:

Reject. A receiving server can reject the incoming email during the connection stage while the sending server is still connected. If a message is rejected at connect time with a 5xx error code, then the sending server can report the problem to the real sender cleanly

Bounce. A receiving server can initially accept the full message, but then determine that it is spam or to a non-existent recipient, and generate a bounce message back to the supposed sender indicating that message delivery failed.

This is detailed in the wiki entry here: Backscatter (email) - Wikipedia

 

[keat63]

 

[rackaid]

In terms of blacklist, backscatter can land your server on a blacklist. Backscatter used to be a common spam tactic. Spammers would flood your server with a spoofed reply-to. The email contents often contained phishing or malware links. This was so much of an issue there's even a specific RBL (http://www.backscatterer.org/) designed to address the issue.

This is why I always recommend these setting for cPanel:
- Reject email to unkown users.
- Do not use catch-alls

Catch-all emails are problematic because many spammers simply flood email to "username"@domain.com where username is from a large list of common names. With a catch-all, your server will accept all of these emails. The email address then becomes verified by the spammer. These names will then be put on target lists that circulate on the net. The result -- more and more spam coming to the server.

You are better off having 1000 email aliases than having a catch-all.

 

[keat63]

I just recently changed tweak settings > Initial default/catch-all forwarder destination to fail

 

[sparek-3]

To expand a bit on what @rackaid said - setting your catch all to fail and outright reject messages is generally best. But... if you set your catchall address to deliver mail to a local (i.e. ... not a forwarder or an address that is off of the server) then it should not be problematic (other than allowing spammers to flag the address as verified and receiving a ton of spam). I also agree... it's better to have 1000 different email aliases that funnel into a single account than to use the catchall address. But simply using the catchall address to accept mail locally won't really generate any backscatter.

Now... it's also important to note that the catchall's fail option is totally different than using a filter to fail messages.

The catchall's fail option rejects message at SMTP time - messages never get accepted by your server. No backscatter is generated then.

Using a filter (account level or user level) to fail messages is a bad thing - it will generate backscatter. This is because these filters are only applied after a message is accepted. So essentially your server will accept a message from an email address (that may not be a real email address and won't receive a bounce back message), runs it through the filtering system, decide that the message shouldn't be accepted, and then your server sends back a bounce back message. This is backscatter. That email address that your server is sending the bounce back message to may or may not exist, and it may be someone else's random email address - they didn't send you the message but now they are getting your bounce back message.

I detailed this a long time ago:

Remove Fail from email filter options - Backscatter

Is this how new feature requests is suppose to work? Make a new feature request and then start a thread on the forums to plug that feature request? I've made a feature request to request cPanel to remove the Fail With Message option from email filter's in end-user's cPanel: Remove Fail from...

forums.cpanel.net

but it never got a lot of traction.

The bottom line... you cannot accept an email into your mail queue and then decide to reject it. That's going to generate backscatter.

 

[cPanelLauren]

The bottom line... you cannot accept an email into your mail queue and then decide to reject it. That's going to generate backscatter.

I just want to 2nd (3rd?) this sentiment:

It is ALWAYS better to reject at SMTP time while that connection is open than to BOUNCE a message which happens after the connection is closed. Any opportunity you have to utilize REJECT instead should be taken advantage of.

 

[sparek-3]

Any opportunity you have to utilize REJECT instead should be taken advantage of.

Except... this isn't what happens when you set up a filter to fail a message.

Perhaps there's confusion in the word fail that needs to be address.

In the Default Address section:

Discard the email while your server processes it by SMTP time with an error message. Failure Message (seen by sender)

This essentially means that:

*: :fail: my message

is added/modified in the /etc/valiases/domain.tld file. Note the word fail being used here. This is what chirpy told us to do so many years ago. This fails at SMTP time. This is good.

Now in the email filters sections there is an Action:

Fail With Message

Which - I believe - people tend to think will act the same way as - Discard the email while your server processes it by SMTP time with an error message. Failure Message (seen by sender) - but it does not. Filter processing isn't done until AFTER the message is accepted by the server. It's during that processing time that the FAIL is hit.

It is my opinion that Fail With Message should not be an option in the filtering section because of the way it acts. If you accept a message into your queue but then decide you don't actually want to read it... it should be silently discarded. I just don't know what good Fail With Message does here. It just serves to create a lot of confusion because end users think it acts in a way different than what it actually acts.

 

[cPanelLauren]

@sparek-3

Now in the email filters sections there is an Action:

Fail With Message

Which - I believe - people tend to think will act the same way as - Discard the email while your server processes it by SMTP time with an error message. Failure Message (seen by sender) - but it does not. Filter processing isn't done until AFTER the message is accepted by the server. It's during that processing time that the FAIL is hit.

You are 100% correct:

This is not what happens when you select this at all. This is really "Bounce" With message. This can be evidenced with the following:

(Don't use this filter, I just needed to create something extremely simple to show this)

#failtest
if
 $header_from: contains "gmail.com"
then
 if error_message then save "/dev/null" 660 else fail "Go Away" endif
endif

[[email protected] db]# exigrep 1iuPaa-000ANV-S6 /var/log/exim_mainlog
2020-01-22 17:39:13.744 [39904] cwd=/var/spool/exim 3 args: /usr/sbin/exim -Mc 1iuPaa-000ANV-S6
2020-01-22 17:39:13.804 [39907] cwd=/var/spool/exim 7 args: /usr/sbin/exim -t -oem -oi -f <> -E1iuPaa-000ANV-S6
2020-01-22 17:39:13.700 [39897] 1iuPaa-000ANV-S6 H=mail-wr1-f53.google.com [209.85.221.53]:34170 I=[<MYIPAddress>]:25 Warning: "SpamAssassin as lauren detected message as spam (4.6)"
2020-01-22 17:39:13.731 [39897] 1iuPaa-000ANV-S6 H=mail-wr1-f53.google.com [209.85.221.53]:34170 I=[<MYIPAddress>]:25 Warning: Message has been scanned: no virus or other harmful content was found
2020-01-22 17:39:13.733 [39897] 1iuPaa-000ANV-S6 <= [email protected] H=mail-wr1-f53.google.com [209.85.221.53]:34170 I=[<MYIPAddress>]:25 P=esmtps L- X=TLS1.2:ECDHE-RSA-AES128-GCM-SHA256:128 CV=no SNI="mydomain.us" S=4484 M8S=0 RT=0.117s [email protected]l.com T="test" from <[email protected]> for [email protected]
2020-01-22 17:39:13.797 [39904] 1iuPaa-000ANV-S6 ** [email protected] F=<[email protected]> R=central_filter: Go Away
2020-01-22 17:39:14.576 [39904] 1iuPaa-000ANV-S6 Completed QT=1.705s
2020-01-22 17:39:14.580 [39908] cwd=/var/spool/exim 3 args: /usr/sbin/exim -Mc 1iuPab-000ANf-Q1
2020-01-22 17:39:14.569 [39907] 1iuPab-000ANf-Q1 U=mailnull Warning: "SpamAssassin as cpaneleximscanner detected OUTGOING not smtp message as NOT spam (0.8/20)"
2020-01-22 17:39:14.572 [39907] 1iuPab-000ANf-Q1 <= <> R=1iuPaa-000ANV-S6 U=mailnull P=local S=5810 M8S=0 RT=0.022s id*[email protected] T="Mail delivery failed: returning message to sender" from <> for [email protected]
2020-01-22 17:39:14.636 [39908] 1iuPab-000ANf-Q1 Sender identification U=mailnull D=-system- S=mailnull
2020-01-22 17:39:15.160 [39908] 1iuPab-000ANf-Q1 => [email protected] F=<> P=<> R=dkim_lookuphost T=dkim_remote_smtp S=6470 H=gmail-smtp-in.l.google.com [172.217.195.26]:25 I=[<MYIP>]:45682 X=TLS1.2:ECDHE-RSA-AES128-GCM-SHA256:128 CV=yes DN="/C=US/ST=California/L=Mountain View/O=Google LLC/CN=mx.google.com" L C="250 2.0.0 OK  1579736355 n8si169071otr.102 - gsmtp" QT=1.353s DT=0.432s
2020-01-22 17:39:15.160 [39908] 1iuPab-000ANf-Q1 Completed QT=1.353s

***Sorry for the ridiculous logging, I have everything being logged on my test server and pay no attention to the fact that GMAIL is being flagged as spam - also something I am testing.

 

[sparek-3]

And when [email protected] becomes [email protected] or even [email protected], then:


2020-01-22 17:39:15.160 [39908] 1iuPab-000ANf-Q1 => [email protected] F=<> P=<> R=dkim_lookuphost T=dkim_remote_smtp S=6470 H=gmail-smtp-in.l.google.com [172.217.195.26]:25 I=[<MYIP>]:45682 X=TLS1.2:ECDHE-RSA-AES128-GCM-SHA256:128 CV=yes DN="/C=US/ST=California/L=Mountain View/O=Google LLC/CN=mx.google.com" L C="250 2.0.0 OK 1579736355 n8si169071otr.102 - gsmtp" QT=1.353s DT=0.432s
2020-01-22 17:39:15.160 [39908] 1iuPab-000ANf-Q1 Completed QT=1.353s

becomes

2020-01-22 17:39:15.160 [39908] 1iuPab-000ANf-Q1 ... not going to look up the exact log syntax ... but now I'm a message ID (1iuPab-000ANf-Q1) that will exist in your mail servers queue and never go anywhere

 

[keat63]

Some very interesting info here folks, all makes sense.

Any thoughts on how I might go about this scenario.

We have an internal application which sends out customer invoices.
I have a dedicated email address for this purpose.
Despite, the footer in all email messages which says 'This mailbox not monitored, do not respond', customers still respond.
I guess no one can read.

So foolishly, I have an auto responder on that mailbox which says words along the lines 'I'm sorry, but your messge has reached an unmanned mailbox, please call us instead'

How would I go about fixing this, so that all messages would fail at smtp time instead.

 

[sparek-3]

Well... a couple of things.

First, you'd have to delete the email account (and any forwarders) for this email address, and let incoming mail for this email address be handled by the default (catchall) address ... which I assume you would have set to Discard the email while your server processes it by SMTP time with an error message. Failure Message (seen by sender).

A note here... you don't have to have an email address set up to send a message FROM that address. You will (likely) have to authenticate with a valid email account's username and password to send out mail from your server... but the email account you use to authenticate with does not have to be the same email account you use in the FROM line.

Further note... the only time sending mail from an email address that does not exist is if the recipient end (the mail server that you are sending one of these messages to) has their mail server configured to do a full sender callback (or callout). With a sender callback, the receiving server will connect back to the mail server handling mail for the domain name (your server) and start an SMTP transaction to send an email to this FROM address. If that fails (which it will if you do not have the email address set up) then the message is (likely) rejected by the receiving server.

Further note number 2... there's a misconception that the MESSAGE you put in the Discard the email while your server processes it by SMTP time with an error message. Failure Message (seen by sender) is an autoresponder... it's not. This message is what your server says to the remote when a remote server tries to send an email to an email address that does not exist. This remote server would then be responsible for sending a bounceback or other message to the original sender. Whether it includes this MESSAGE is up to the remote SMTP server.

In the scenario you have layed out, if someone sends a message to the email address and you do not have it set up and it gets processed by the catchall address which is set to Discard the email while your server processes it by SMTP time with an error message. Failure Message (seen by sender), then the original sender is just going to get a non-deliverable message which may or may not include the content of your MESSAGE.


The other solution is to set up a filter for this email address - but set the ACTION to Discard Message - this will silently delete the message. You won't get it and as far the original sender goes they will be none the wiser that you did not get the message. Harsh? Perhaps. But as you say... people need to learn to read.


Another solution is to just keep your current set up (but remove the autoresponders... autoresponders are bad) and let mail collect for this email address. Maybe monitor it - maybe not. This is what we typically do. We do not respond to requests immediately that are replied to... because again as you say, people need to learn to read. We will sometimes wait a day or two (or more) before responding to any requests. Usually, if the request is important to the user I suppose they either re-read the notice and figure it out or just go to our website and submit a ticket (which is what the original notice said do).

 

[hiredgeek]

Thank you @sparek-3 for the explanation of what happens with filters.

In cPanel > Forwarders > Add Forwarder, I see the following option:
"Discard and send an error to the sender (at SMTP time). Failure Message (seen by sender)"

That is a Forwarder, not a filter, but it seems like it would be a helpful solution that hasn't been mentioned here.

I have a [email protected] that I use with SMTP to authenticate outgoing email.
I'd like to add a Forwarder and set it to Discard at SMTP time.

If I'm understanding correctly, a Forwarder would solve the problems and notes mentioned in this post:

• It rejects at SMTP time (not bounce)
• It would not cause backscatter
• The sending email address exists and is being authenticated
• AND the replying user would get a response.
  
  Please let me know if I'm incorrect.
  
  

 

[sparek-3]

Well...

The common misconception is that you have to use an SMTP authentication email address as the same email address you are sending a message from.

There's two parts of SMTP Authentication (well... I guess this should be "two parts to SMTP that requires SMTP Authentication" ... a little wordy).

SMTP Authentication is one thing.

The SMTP transaction - the part that actually sends a message - is another thing.

One does not necessarily depend on the other.


The only thing SMTP Authentication is doing is authenticating that the connecting client has permission to send mail out through the sever. That's it. You can even cross-account authenticate - authenticate with an email account from one web hosting account and send out mail using a from address of another web hosting account - so long as the two web hosting accounts are on the same server.

So from this information - you don't necessarily have to have [email protected] set up as an email account in order to send out mail from [email protected]

If I'm intending to use an email account solely for SMTP authentication purposes, I'm more likely to create a long and random email account - i.e. [email protected] - and then use that email account's login information to utilize SMTP authentication.

Then I can set whatever From address I want to use from within my email client (although this may or may not be more difficult depending on what email client you use... Linux's CLI mutt for the win!).

For the purpose of this specific scenario, I'd recommend setting up an SMTP authentication email account and using that to authenticate with the SMTP server. Then I'd set [email protected] as a forwarder and set it to Discard (Not Recommended). (This is :blackhole: for anyone keeping score) Why Discard? Because IF you send an email to a mail server that happens to use a sender callout, then if you [email protected] set to Discard and send an error to the sender (at SMTP time) (This is :fail: for anyone keeping score) - that server will not accept your message because the callout will fail. I do not know how prominent sender callouts really are - they're probably not too widely used.

Again, the issue with :fail: in this context and the line in cPanel - Failure Message (seen by sender) is a bit misleading. In this context - sender - refers to the mail server sending the message, not necessarily the human being sitting behind the desk that clicked Send when sending the message.

When a human being sends a message to an email address that ultimately ends at a :fail: end-point, the :fail: message is going to be sent back to the SMTP server that the human being used to send out their message. What that SMTP server does with the :fail: message just depends on that SMTP server. Does it send the :fail: message back to the original human being sender? Maybe. Or maybe it just sends a generic "We could not deliver your message" message back to the human being.

The downside to using :blackhole: is that any human being that sends a message to an email address that ultimately goes to :blackhole: then they are none the wiser that the message wasn't read by anyone. But I assume you've told your users not to reply back to the [email protected] email address. And as the name implies... noreply... [email protected] But, I'm also aware that reading comprehension - at least in this country - has taken a major hit and if you can't say something in 140 characters or less... it's not going to be read. ... Much like this thread reply, will anybody ever read this far down?

 

[hiredgeek]

After some further research, I realize I shouldn't use a [email protected] email address because many mail servers flag that as spam, it can't be whitelisted, and it increases user complaints, etc.
I apologize for sidetracking us with the [email protected] address, but it's certainly good info as well.

I'm leaning towards having actual email boxes and occasionally checking those boxes, as that seems to be the best practice.
Especially if the scenario is with invoices like the OP, then many companies might want to monitor replies, just in case.

However, IF the OP was to still want to reject email and reply with a (sometimes generic) message, then it sounds like a Forwarder would still be the best bet. (As sparek-3 has been mentioning, a filter is not a good idea).

Let's say the OP uses [email protected] to authenticate SMTP, and then uses a Forwarder on it to:
"Discard and send an error to the sender (at SMTP time)."

1. The [email protected] address would have better deliverability than a [email protected]
2. Using the same address to authenticate AND send would satisfy sender callouts.
3. No backscatter.
4. Rejects at SMTP time.
5. Owner would have the option to simply remove the discard Forwarder and start checking their inbox if desired.

As an additional note, I believe a dedicated [email protected] inbox could be used for the return-path, which could be monitored by some bounce management software. This would further improve deliverability by ensuring invoices are not going out to non-existent or bounced addresses.

But again, my above notes are only if you don't want to check the inboxes or interact with customers.