Hi there, On Mon, 7 Feb 2022, Marc wrote:
Normally when a client connection is reject by my sendmail server, the client is notified of the Reject message and the client server is generating a NDR. This is listed in my log as [1] however when I send a virus it looks like sendmail is not reporting the reject back to the client server. How should I 'enable' this?
This isn't a ClamAV question, more one about Sendmail configuration and MTA/client behaviour. If I've understood what you've said you want, and your configuration, it all seems OK. Both log snippets show a rejection in replies which are made to the client. They do not however show any NDR, they're just parts of the client/MTA conversation which starts with "connect from" and can be terminated by the MTA more or less at any point during what follows, right up to the final '.' on a line on its own. If the MTA terminates with a 4xx code or 5xx code the message[*] is considered rejected (respectively either temporarily or permanently) and the client MAY take some optional text attached to the reply by the MTA and use it in an NDR which it creates for return to the originator of the mail. In this case the MTA does not create the NDR, it's up to the client, i.e. the administrators at the client end. If the rejection is temporary most clients wait for a configurable while and then have another try, without informing the sender that there's been a delay. They may send a notification after a couple of hours, something like "you do not need to take any action, this is just a warning of a delay" and if there's no luck sending the message after two to five days they may send a final "I gave up" note. But by no means all MTAs do that, again it's up to the administrators. If the MTA actually accepts the message but later on finds that it's undeliverable then according to the RFCs it must create an NDR itself (but that doesn't appear to be the case in either of your examples). If you're thinking about what are sometimes called 'bounce' messages, where a message is received (and accepted) by an MTA and it promptly replies to that message with one of its own saying that the message has been dropped in the trash can, then please don't do that because it will likely add to the problems caused by the original message. Some of us might say it's safer to use more than one single indicator to determine that a rejection is called for, but that's up to you. [*] Simplified here - it could be a recipient, not the whole message, which is rejected. There are lots of resources on the Web describing mail client/MTA conversations in as much detail as anyone could want. -- 73, Ged. _______________________________________________ clamav-users mailing list clamav-users@lists.clamav.net https://lists.clamav.net/mailman/listinfo/clamav-users Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
