Exchange Sending outbound email

The undeliverable is send from which server ... it would be listed on the NDR.

Is there any Transport rule ?
ARe you saying a user tries to send some external email and is rejected ? Is so please check the Transport filters or settings on GFI or Antispam.

- Rancy

Hi

The NDR is sent from Exchange Server (its part of the SBS server).  

I dont think there is any transport rules, just applied the default settings.

No I am saying, the emails are rejected before it hits the inbound SMTP queue where it gets processed by the GFI spam filter.  So the mail does not appear in the monitor. It gets rejected and an NDR is sent out.

regards

SO if the email isnt getting to the Exchange Transport Queu than it most probably GFI or Antispam ... but Antispam is still being worked with Transport service ... if possible try to stop the GFI and check.

- Rancy

//SO if the email isnt getting to the Exchange Transport Queu than it most probably GFI or Antispam ... but Antispam is still being worked with Transport service ... if possible try to stop the GFI and check.//

Sorry how can I check this Exchange Transport Queue? Where I mean?

Its not GFI because, GFI will only process the email when it hits SMTP queue, at the moment I can see the email is being pulled down by the POP3 connector on the gateway machine and handed over to the Exchange Server then it vanishes. I cant find any trace of it, only an NDR is sent out by the Exchange server. It looks like Exchange server is doing this. But I have disabled its anti-spam feature.

I have also disabled NDR (unticked it) in the "Remote Domains" properties under the message format tab.

Queue viewer in Toolbox in EMC ..... you can also try to Track the message using Exchange Shell.

Unticking NDR will not send the NDR but wouldnt send the email ..

So the Profile is POP3 ?
SO is the email sent by an internal user to another internal user ? If so was there any attachment to it ?

- Rancy

This is the cause of your problems:
"POP3 connector on the gateway machine "

Exchange is not designed to be used with a POP3 connector. It will download all email, whether it is for a valid user or not, then attempt to deliver it and NDR it. Not much you can do about it in that configuration, and you aren't getting the best from your GFI product either.

Dump the POP3 connector, there are almost no valid reasons for using it. Get your email delivered by SMTP which is how Exchange is designed to work. Then you can filter email for non-existent users at the point of delivery.

Simon.

Hi Simon

I have been using this method for years and so have many others. There are good reasons to use POP3 to download to a gateway machine and then forward that to the Exchange server using SMTP, so your argument that it should be delivered by SMTP is talking place anyway.
 Nor have I seen any documents which suggest the Exchange server will not work well with a gateway machine delivering by SMTP

Regards

Just because you have been using a poor solution for years doesn't mean it is a good solution. That is the drunk drivers excuse. Most drunk drivers will say they have been driving for years while drunk - that means nothing when one night they crash in to another car killing themselves and the other driver. Drunk driving became taboo in the 1980s and that is also where POP3 connectors should be left.

My argument is that you should be delivering email by SMTP without the use of the POP3 connector completely, so that on delivery filtering can take place. The configuration that you are currently using will get you blacklisted if you were attacked, as you cannot stop backscatter because your primary delivery point is unable to filter for unknown recipients at the point of delivery.
Furthermore you are wasting a lot of bandwidth downloading email that you don't want because you cannot filter it out. I have clients that drop 80% of all email being delivered because it is garbage, another client saw their Internet connection usage drop by over 70% simply by adopting best practises for email filtering.

I am sorry to say, but the use of the POP3 Connector is the cause of your problem, and while you continue to use it, the problems you have seen will not go away.

Simon.

//My argument is that you should be delivering email by SMTP without the use of the POP3 connector completely, so that on delivery filtering can take place.//

I do not understand this point. That filtering is taking place anyway upon delivery to the Exchange server. The only point is the emails are first delivered to our mail server and then downloaded from there by a gateway machine and sent to the exchange server. So what is the issue you are trying to highlight here? Is this anyway related to my problem?

//The configuration that you are currently using will get you blacklisted if you were attacked, as you cannot stop backscatter because your primary delivery point is unable to filter for unknown recipients at the point of delivery. //

My primary email server only takes delivery for a specified number of accounts with no catch all. So that would take care of backscatter?


//Furthermore you are wasting a lot of bandwidth downloading email that you don't want because you cannot filter it out. I have clients that drop 80% of all email being delivered because it is garbage, another client saw their Internet connection usage drop by over 70% simply by adopting best practises for email filtering. //

This I accept. But our primary email server do filter to some extent.

As you aren't using Exchange for primary delivery, you are going to get NDRs being sent by Exchange, which will be backscatter. Unfortunately the NDR you have posted isn't complete, so it isn't clear why it was NDR'd.

Simon.

// you are going to get NDRs being sent by Exchange,//

There must be a way to stop the Exchange Server sending out NDRs?

Depends what the reason is for the NDR.
The only NDRs that you can stop are those where Exchange accepts the email and then rejects the message, which is also backscatter. If Exchange is rejecting the email at the point of delivery from your gateway, then those cannot be stopped.

Simon.

I simply turned off the NDR and the problem was cured.