-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > From: Vikram Goyal <[email protected]> > To: [email protected] > Subject: [OT] sendmail query to relay but suppress rejection messages
> My query is not related to mutt as such but sendmail, so please excuse > me if it bothers you. > > I need to tweak sendmail in such a way that it does not sends back > rejection messages back to one of the sending machine. The mails are all > for local domain but the sending software is proprietary and breaks down > on such messages. > > I looked through the net and found some tips. Will the following entries > in access db do the job: > > 172.16.0.100 RELAY > 172.16.0.100 5.2.1 DISCARD > > Can these be combined together? It's been a while since I've used sendmail's accessdb, but I'll try to take an educated guess. As far as I can remember, the RHS of accessdb rules are a set of mutually exclusive actions. According to <http://www.faqs.org/docs/securing/chap22sec178.html> your first accessdb line instructs sendmail to relay messages destined for 172.16.0.100. The second line instructs sendmail to reject messages for 172.16.0.100 with SMTP status code 5.2.1, and the error text "REJECT". But you should test this yourself, rather than taking my word for it :) This is a difficult question to answer without knowing how your delivery network is set up, but I can offer two suggestions. I am _assuming_ that you want <some-user>@[172.16.0.100] to receive "ordinary" mail, but that you don't want <some-user>@[172.16.0.100] to receive delivery status notifications (DSNs). Normally, and MTA will deliver DSNs to the message envelope FROM address (presumed to be <some-user> here). Sendmail gives you the option of using the Errors-To header to specify where DSNs should be delivered. See <http://www.sendmail.org/doc/sendmail-current/doc/op/op.pdf>, section 2.9.1. However, that's a deprecated feature. If your mail is handled by any out-of-network hosts, you'll find that many of them ignore Errors-To. A second approach is to treat this like a spam filtering problem. * Have <some-user>@[172.16.0.100] deliver mail to a filtering program. (e.g., procmail) * Have the filtering program discard DSNs. * Have the filtering program remail "ordinary" messages to <some-user-filtered>@[172.16.0.100] * Have <some-user-filtered>@[172.16.0.100] deliver mail to your application. Hope that helps. Steve -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (Darwin) iEYEARECAAYFAkoZbZEACgkQX7YJI4BuyDRGggCgsTgOBCtA1ZdOC2nEqYX0JmOD jBcAn2VFNIunkZaVmu4sCmg8s8KsD7KH =eXuP -----END PGP SIGNATURE-----
