Yes, we are having an issue that I am not sure if it is related to us or not. We are running Exchange 2007 SP3 installed on Windows Server Enterprise x64 R2 SP2. We have been receiving complaints that external users aren't receiving an NDR 5.2.3 when they are send an email with too large of attachment. I understand that our server will only terminate the SMTP request and send the error code, and the MTA server will generate the NDR for the user. We have tested this against multiple mail servers sending to us (hotmail, gmail, other companies) and no one is receiving one. We do receive an NDR for other items (such as non-existant mailbox, etc). Would this be an issue related to our server perhaps not sending the error code, or would it be an issue with the MTA not generating the NDR?

On Wed, 9 Feb 2011 14:18:36 +0000, Craig R3 wrote: > > >Yes, we are having an issue that I am not sure if it is related to us or not. > >We are running Exchange 2007 SP3 installed on Windows Server Enterprise x64 R2 SP2. We have been receiving complaints that external users aren't receiving an NDR 5.2.3 when they are send an email with too large of attachment. I understand that our server will only terminate the SMTP request and send the error code, and the MTA server will generate the NDR for the user. Not necessarily. It depends on when the error is detected. If your server accepts the message for delivery and later decides the message can't be delivered then it's your server that sends the NDR. OTOH, if your server never accepts the message for delivery then it's the transmitting server that genertes the NDR. >We have tested this against multiple mail servers sending to us (hotmail, gmail, other companies) and no one is receiving one. We do receive an NDR for other items (such as non-existant mailbox, etc). Do you limit the size of the inbound messages? Have you checked the SMTP protocol log to see if the sender's using SMTP (i.e. they send HELO) or ESMTP (they send EHLO) and if your server includes the "250-SIZE X" in the list of keywords? >Would this be an issue related to our server perhaps not sending the error code, or would it be an issue with the MTA not generating the NDR? Check the default "Remote Domain" and see if you've suppressed the sending of NDRs. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Rich, Thanks for the reply. Please see my responses below: 1. I can tell that our exchange server is at least receiving the message. If I view the Message Tracking logs, I can see them listed as a "FAIL" eventid. I can usually see them briefly in the Que also. Now whether or not that is what you meant, I am not sure. 2. We do limit the size of inbound messages. Overall, we allow 10mb emails, though we limit 99% of users to 5mb. So while we can receive 10mb, based on the user it should fail if over 5mb, which is where our problem lies. 3. I have already verified that we are sending NDRs. I have also verified that if I send an email to a non-existant address, ex: unknownuser@mycompany.com, we receive a NDR almost immediately. So that doesn't seem to be the issue. 4. I verified that we didn't have SMTP logging enabled. I went ahead and enabled it, not that it will allow me to see previous issues. I will have to send out a few test emails to see what I come up with now. Thanks, Craig R.

On Thu, 10 Feb 2011 14:27:22 +0000, Craig R3 wrote: >1. I can tell that our exchange server is at least receiving the message. If I view the Message Tracking logs, I can see them listed as a "FAIL" eventid. I can usually see them briefly in the Que also. Now whether or not that is what you meant, I am not sure. Seeing the "FAIL" even means you server should send the NDR. Seeing the NDRs in a queue isn't important. >2. We do limit the size of inbound messages. Overall, we allow 10mb emails, though we limit 99% of users to 5mb. So while we can receive 10mb, based on the user it should fail if over 5mb, which is where our problem lies. Okay. So your server accepts the message for delivery. If it can't deliver the message it should send a NDR. Now go check the various Remote Domains in your organization and verify that you haven't uncheck the box that says you allow NDRs to be sent out of your organization. >3. I have already verified that we are sending NDRs. I have also verified that if I send an email to a non-existant address, ex: unknownuser@mycompany.com, we receive a NDR almost immediately. So that doesn't seem to be the issue. Your server shouldn't be sending a NDR, it should just send a 5xx status message when a RCPT TO address is incorrect. The sending server sends the NDR. >4. I verified that we didn't have SMTP logging enabled. I went ahead and enabled it, not that it will allow me to see previous issues. I will have to send out a few test emails to see what I come up with now. Okay. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

On Thu, 10 Feb 2011 14:27:22 +0000, Craig R3 wrote: >Seeing the "FAIL" even means you server should send the NDR. Seeing the NDRs in a queue isn't important. Rich, I didn't mean that I could see the NDR in the que, I meant I could see the message that was being sent to us briefly in the que, not that it really matters. As you said, since the Message Logs are recording that they received the message and gave it a status, in this case FAIL, our server should be sending the error code for the remote server to send the appropriate NDR. >Okay. So your server accepts the message for delivery. If it can't deliver the message it should send a NDR. Now go check the various Remote Domains in your organization and verify that you haven't uncheck the box that says you allow NDRs to be sent out of your organization. I have reverified that we have the options checked to allow sending NDR in our Remote Domain under Hub Transport. >Your server shouldn't be sending a NDR, it should just send a 5xx status message when a RCPT TO address is incorrect. The sending server sends the NDR. I meant it should be sending the error code for the NDR :) >Okay. Still needing to parse our SMTP logs, yesterday wasn't a good day. Hopefully can get to that here shortly. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP