When my sendmail (8.13.8) daemon finds a previously-accepted message
to be undeliverable, it generates a DSN message having a body
containing contents such as:

< myserver01.mydomain.com #5.1.1 SMTP; 550 5.1.1
<123123@mydomain.com>... User unknown>

Here, myserver01.mydomain.com is my sever (the reporting MTA) and 550
5.1.1 is the rejection I received attempting to route this message to
some remote MTA.

Anyhow, I am being compelled to look into reconfiguring sendmail so
that it omits including its hostname in messages of this type.
Personally I believe this to be a misguided pursuit, however I am
interested in two things:

1. can this be accomplished and if so how?
2. would this explicitly violate standards?

Thanks in advance for any feedback which I do greatly appreciate.

[user@myserver01 user]$ sendmail -d0.1
Version 8.13.8
Compiled with: DNSMAP HESIOD HES_GETMAILHOST LDAPMAP LDAP_REFERRALS
LOG
MAP_REGEX MATCHGECOS MILTER MIME7TO8 MIME8TO7
NAMED_BIND
NETINET NETINET6 NETUNIX NEWDB NIS PIPELINING SASL
SCANF
SOCKETMAP STARTTLS TCPWRAPPERS USERDB USE_LDAP_INIT

In article <1188778204.933534.290580@50g2000hsm.googlegroups. com>,
decourl@gmail.com wrote:

> When my sendmail (8.13.8) daemon finds a previously-accepted message
> to be undeliverable, it generates a DSN message having a body
> containing contents such as:
>
> < myserver01.mydomain.com #5.1.1 SMTP; 550 5.1.1
> <123123@mydomain.com>... User unknown>
>
> Here, myserver01.mydomain.com is my sever (the reporting MTA) and 550
> 5.1.1 is the rejection I received attempting to route this message to
> some remote MTA.

Are you using Exchange?

The reason I ask is because Exchange by default builds godawful idiotic
DSN messages with lines that look just like that, and *dumps* the rest
of the standard DSN. This is because it is designed and coded by worse
fools than its users. There's a registry setting to make Exchange not
do that stupid discarding of useful information, but you have to
understand that it is doing so and go hunting at the MS site to fix it.

If you are not using Exchange, I'm surprised that you managed to put
exactly that line together...

> Anyhow, I am being compelled to look into reconfiguring sendmail so
> that it omits including its hostname in messages of this type.

You need to explain the insanity of that to whoever is compelling you.

DSN's exist to alert senders to problems with delivery. Hiding the
source of the DSN makes them useless. Not that you could really hide the
source completely, but you could make it hard to figure out,
particularly for people trapped behind Exchange...

> Personally I believe this to be a misguided pursuit, however I am
> interested in two things:
>
> 1. can this be accomplished and if so how?

You cannot configure the hostname out of the DSN, but you could code it
away, and the Sendmail code is freely available. Doing so would be
insanely antisocial. You're better off just breaking your mail system by
not sending any DSN's ever.

(and no, I won't explain how to do that, because It Would Be Wrong.)

> 2. would this explicitly violate standards?

Absolutely. Sendmail generates standard DSN's. Standard DSN's identify
the host that generates them.

There are reasons to be selective about when you send DSN's and when you
don't, and reasons to try to reduce the incidence of good cause to send
DSN's. Sending broken DSN's is never right.

--
Now where did I hide that website...

In article <1188778204.933534.290580@50g2000hsm.googlegroups. com>,
decourl@gmail.com wrote:

> When my sendmail (8.13.8) daemon finds a previously-accepted message
> to be undeliverable, it generates a DSN message having a body
> containing contents such as:
>
> < myserver01.mydomain.com #5.1.1 SMTP; 550 5.1.1
> <123123@mydomain.com>... User unknown>
>
> Here, myserver01.mydomain.com is my sever (the reporting MTA) and 550
> 5.1.1 is the rejection I received attempting to route this message to
> some remote MTA.

Are you using Exchange?

The reason I ask is because Exchange by default builds godawful idiotic
DSN messages with lines that look just like that, and *dumps* the rest
of the standard DSN. This is because it is designed and coded by worse
fools than its users. There's a registry setting to make Exchange not
do that stupid discarding of useful information, but you have to
understand that it is doing so and go hunting at the MS site to fix it.

If you are not using Exchange, I'm surprised that you managed to put
exactly that line together...

> Anyhow, I am being compelled to look into reconfiguring sendmail so
> that it omits including its hostname in messages of this type.

You need to explain the insanity of that to whoever is compelling you.

DSN's exist to alert senders to problems with delivery. Hiding the
source of the DSN makes them useless. Not that you could really hide the
source completely, but you could make it hard to figure out,
particularly for people trapped behind Exchange...

> Personally I believe this to be a misguided pursuit, however I am
> interested in two things:
>
> 1. can this be accomplished and if so how?

You cannot configure the hostname out of the DSN, but you could code it
away, and the Sendmail code is freely available. Doing so would be
insanely antisocial. You're better off just breaking your mail system by
not sending any DSN's ever.

(and no, I won't explain how to do that, because It Would Be Wrong.)

> 2. would this explicitly violate standards?

Absolutely. Sendmail generates standard DSN's. Standard DSN's identify
the host that generates them.

There are reasons to be selective about when you send DSN's and when you
don't, and reasons to try to reduce the incidence of good cause to send
DSN's. Sending broken DSN's is never right.

--
Now where did I hide that website...

On Sep 2, 10:46 pm, Bill Cole <b...@scconsult.com> wrote:
> Are you using Exchange?
>
> The reason I ask is because Exchange by default builds godawful idiotic
> DSN messages with lines that look just like that, and *dumps* the rest
> of the standard DSN. This is because it is designed and coded by worse
> fools than its users.

Thanks for the tip on that. I had often thought that "[Reporting MTA]
[Response from uncited Remote MTA]" was an anti-intuitive,
uninformative, and terse format to issue a DSN in. It gives me
comfort, after directing a couple of DSNs to mail spool via local
delivery, to see that this is not the work of sendmail. I'd have to
rate this "feature" right up there with SMTP FIXUP.