Re: [OT] sendmail query to relay but suppress rejection messages
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> From: Vikram Goyal <vikigoyal@xxxxxxxxx>
> To: mutt-users@xxxxxxxx
> 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-----