Hello,

I've found an strange behavior with SpamFilter, Exchange Server 2013 and Exchange recipient filter feature enabled.

When a user sends an email and he types a bad address along with a good address, the message is NOT delivered to the good address and Spamfilter logs a "User unknown error" and tries to send a NDR to Sender.

For example, lets suppose I send an email like:

From: Someone@gmail.com

To: validuser@domain.com, InvalidUser@domain.com

Subject: Whatever...

Tracing LOG files at SpamFilter I can see that message is correctly sent to the Exchange Server at domain.com after all the internal spam checks (SPF, Bayesian,SFDB,  etc, etc) that is  "Created thread (XXXXXX) to handle delivery"

From Exchange Server side I can see that message arrives correctly and Exchange detects that one of the recipients is invalid because it doesn't exist at the company. Exchange sends back a Recipient OK for validuser@domain.com and also sends back a User Unknown for InvalidUser@domain.com

It seems that SpamFilter is just processing the "User unknown" response and therefore rejects the message without trying to send it for the valid user.

Hope you can help, I can provide LOGS from SpamFilter side and Exchange side if needed.

By the way,  I'm aware that SpamFilter has an "Authorized TO Emails" White List; but by the moment we are not able to Sync this list with our customers Address Books in an efficient way, so they rely on Exchange's recipient filter to reject invalid recipients.

Also worth to note that Exchange 2013 has FrontEnd/BackEnd architecture, that is .. all messages are received by a FrontEnd Server on port 25 with standard SMTP, after analyzing the destination recipients, messages are routed to a BackEnd server depending on which server the mailbox resides; this is valid even if there is only 1 server at the company. Exchange side is NOT USING Edge roles, our customers are seeing SpamFilter as the first line of defense for cleaning spam.

Regards,

   Enrique.

A mail server only knows of a recipient when the sender's SMTP server has issued a "RCPT TO" command during the SMTP session. The mail server does not look inside an email's content to see who the recipients are. Thus the various "To:", "CC:" and "BCC" headers are meaningless to a mail server as they are only part of the content of the email. By the time the content of the email is sent after the DATA command, the sender and the recipients have already been determined via the MAIL FROM and RCPT TO commands.

So in my example, the only two addresses that matter are these two: 

The mail server (both SpamFilter and our destination SMTP server) do not know and do not care if these emails were meant to be part of the TO, CC or BCC addresses - it is irrelevant. All SpamFilter and our mail server need to know is that they need to deliver the content of the email (after the DATA command) to those email addresses. Again - SpamFilter and our mail server do not look inside the body of the email to see what the TO and CC email addresses are and how they compare to the RCPT TO addresses (actually the latest versions SpamFilter will log if they are different, but only to give admins more options to find emails in logs...).

Going back to what you see by turning on and then off the Exchange Recipient Filtering - when you turn it on, your Exchange server will reject the invalid recipient when SpamFilter attempts to forward it the email with the non-existant email address. When this happens, SpamFilter will (correctly) reject the email from the sender by outputting a 5xx error code and in the bounce message will include the rejection notice from your Exchange server.

When you disabled the Recipient Filtering, your Exchange server will accept the email from SpamFilter even though there is an invalid recipient. SpamFilter will see it delivered successfully so as far as SpamFilter is concerned it was delivered. Your Exchange server then, after receiving the email, will see the invalid recipient and will then in turn send a bounce email back to them. Please note that this is an actual email being sent by your Exchange server. It will be sent to whatever email address the sender has specified in their "MAIL FROM" command, which in my example above is:

Note that while in most legitimate emails sent by humans this email address will match the address specified in the "From:" header in an email. However in most emails sent by spammers this will be a spoofed email address belonging often times to an unaware persona/domain, and in case of automated emails, the MAIL FROM email address usually mis-matches the one specified in the "From:" header.

Due to this, with the Recipient Filtering disabled in Exchange, you run in the high risk of having your Exchange server sending large amounts of NDR outbound email in response to spammers and/or automated emails that will be sent to innocent or invalid email addresses.

The recommended way to proceed is to leave the Recipient Filtering enabled, and allowing SpamFilter to reject the email with the incorrect recipient(s). When the sender sends an email with one or more invalid recipients, that sender will always receive a non-deliverable email bounce back. You can either (1) let that happen by having their own ISP send them the bounce NDR (by having SpamFilter reject the email), or (2) by having the NDR email being sent by your own server either by disabling Exchange's Recipient Filtering or by changing SpamFilter's default value for VerifyRCPTTOForCleanEmails=1. 

It's usually better to avoid backscatter originating form your network, saving network resources, and avoiding being blacklisted by going with option 1.

PS - as a side note - the BCC header only appears in the email residing in the sender's own mailbox - the BCC header is stripped when the email client actually sends the email to the mail server

Enrique,

From your logs I believe what you call the front end server is where SpamFilter forwards its emails to. If that is the case, the front end Exchange server is the one that is rejecting the entire message if one of the recipients is incorrect. Furthermore, it does not reject the recipient right away when the RCPT TO command is issued, but rather only at the end of the SMTP session, when the email has been transmitted. To make matters worse, the front end server is not specifying which email address is incorrect - it simply rejects the entire message.

Please note that from your logs I can confirm what I mentioned in the forum - the behavior does not change depending on whether the invalid email address is specified in the CC or in the TO headers - the SMTP session is the same and the front end server rejects it in the same way.

These are the transcripts of what happens to an email sent to eca...@...com.mx and invalid@......com.mx to your front end server at ...........com.mx. The first session is with invalid@.....com.mx entered in the TO field, the second session with invalid@.....com.mx entered as a CC.

As you can see, your front end server accepts both recipients without any errors, and at the end it rejects the entire message with a "550 5.1.1 User unknown" without specifying what is the incorrect user:

As this error occurs *after* the recipients are send and accepted, SpamFilter must (per RFC) assume that the email is not delivered, and at this point SpamFilter does need to send an NDR bounce email back to the sender. Here is another problem however - SpamFilter never sends an NDR directly out to the internet, but rather it forwards the NDR to your destination SMTP server for delivery. In this case, the NDR is send to ..........com.mx, which however does not allow SpamFilter to open relay, so it does not deliver the NDR. You must ensure that your front end server whitelists SpamFilter so that the NDRs can be sent.

Please note that if your front end server had rejected a recipient during the RCPT TO command, then SpamFilter would have known it was an invalid user as I mentioned in the forum, and it would not need to send an NDR since it would instead reject the email specifying in the 550 error code which email address had the problem.

Also please note that I see from your backend server logs that the front end server is forwarding the email to the backend server even though it's reporting the email as being rejected to SpamFilter. This is very confusing as it causes emails to be delivered even though the front end server is reporting to having rejected them as a whole.

I hope this helps a bit in understanding how the email flows and that your front end server should be configured differently. 

To summarize, these are the problems with that front end server:

1. It must whitelist SpamFilter so that NDRs can be delivered

2. It should reject invalid email addresses when the RCPT TO command is used to specify a recipient, not at the end of the email.

3. If it cannot be configured as in #2 above, it must at least specify in the 550 error message which email address was not deliverable so this can be reported back to the sender. Otherwise the error will be interpreted as "your email was not delivered to ANY of the recipients".