I have a 6Mb message size limit set on my SMTP server. When an outgoing email is over the limit, the user gets a non deliverable. When an incoming email is over the limit, my SMTP server rejects it with a 552 error message, but the sender doesn’t receive a non delivery report.
Does the SMTP server produce the NDR? Or does it just reject the email, and the sending server should send the NDR based on the rejection?
Any help would be appreciated.
Gavin
Subject: Server not sending non delivery
A protocol level failure (5xx) while the message is inbound to your Domino server means that responsibility for generating the NDR lies with the server that connected to you and was refused, not with your Domino server.
So far as your Domino server is concerned, the entire transaction was complete on issuing the 552 response and the subsequent closure of the SMTP connection.
Two scenarios seem likely:
1 - the connecting MTA is not generating a DSN correctly
2 - the DSN is being dropped or rejected somewhere along the return path
Neither is your problem.
Subject: RE: Server not sending non delivery
Thanks for that. It was just what I needed to get my boss off my back!!
Gavin
Subject: RE: Server not sending non delivery
One further thought. In my initial response I assumed the bounce was happening at the protocol level (as you seemed to indicate). This requires that the connecting host is using ESMTP and that you have the ESMTP SIZE extension turned on, which seems likely.
But, if the connecting host is not using ESMTP or you do not have the SIZE extension turned on, then the entire message would have to be accepted and placed on the local mail router before any size checking could take place. In this case, the DSN would be generated by your Domino server.
Look in the mail.box for dead DSNs. If they are there, then the MX host for the reverse path of the messaages is rejecting MAIL FROM:<> which is RFC non-compiant behaviour and is not your problem.
If no dead DSNs are there, then your Domino host must have sent them and they have possibly gone dead in another MTA somewhere along the return path (same reason - non-RFC compliance and again not your problem).