I am experiencing some problems related to sendmail's alias expansion when i
t
composes a bounce message. I have a custom implementation which queries for
the existance of an alias, and then passes the RHS of the alias pair to a
custom delivery program. I can configure sendmail not to rewrite the envelop
e
and header with the expanded alias information, but if the delivery program
fails the resulting bounce message does contain the expanded form of the
alias. The expanded alias is a private, internal designator and I need for i
t
to not be exposed.

If I have an incoming email address: "user1@example.com" which resolves to
"Internal Private UID" I need any bounce messages from sendmail to look more
like:

>Subject: Returned mail: see transcript for details
>Auto-Submitted: auto-generated (failure)
>
>This is a MIME-encapsulated message
>
>--i5UE475V005617.1088604247/localhost.localdomain
>
>The original message was received at Wed, 30 Jun 2004 07:03:53 -0700
>from localhost.localdomain [127.0.0.1]
>
>   ----- The following addresses had permanent fatal errors -----
>|"user1@example.com"
>    (reason: Internal error)
>    (expanded from: user1@example.com)

Rather than:

>Subject: Returned mail: see transcript for details
>Auto-Submitted: auto-generated (failure)
>
>This is a MIME-encapsulated message
>
>--i5UE475V005617.1088604247/localhost.localdomain
>
>The original message was received at Wed, 30 Jun 2004 07:03:53 -0700
>from localhost.localdomain [127.0.0.1]
>
>   ----- The following addresses had permanent fatal errors -----
>|"Internal Private UID"
>    (reason: Internal error)
>    (expanded from: user1@example.com)

The string '|"Internal Private UID"' is the RHS of the alias pair
'user1@example.com':'|"Internal Private UID"' the | gets stripped out by
sendmail, and the rest of the string passed to my custom delivery program.

The obvious solution would be to handle the bounce directly from the deliver
y
program, and always return success to sendmail, but multiple LHS aliases can
resolve to the same RHS. Also, in the case of a failure in the delivery
program itself, if sendmail is informed that a delivery has been successful
there could very well emerge a situation where mail is lost and no-one is
notified.

It seems that the most ideal solution would be a way to have the error bounc
e
messages generated from a set of configurable templates but, as far as I can
tell, there is no existing sendmail functionality to do this.

Any help would be appreciated.

--
--------------------------------------------
J Brian Ismay
jismay@unixboxen.net
http://agamemnon.unixboxen.net

[ Post a follow-up to this message ]

jismay@unixboxen.net wrote:
> if the delivery program
> fails the resulting bounce message does contain the expanded form of the
> alias. The expanded alias is a private, internal designator and I need for
 it
> to not be exposed.

Preliminary remark 1: The text of the bounce is hardcoded, so you need
to patch the sendmail sources and recompile to change it. The part
you're interested in is in sendmail/savemail.c (as of 8.13.0).

Preliminary remark 2: Look into that file. You will find *three*
instances of "    (expanded from: %s)". Each has a putline() preceding
it by about 20 lines that allows you to tell which kind of DSN is
handeled there; namely, "The following addresses had permanent fatal
errors", "... transient non-fatal errors", and "... successful delivery
notifications".

Preliminary remark 3: The state of affairs may be more complicated than
what you described. Bounces will contain q->q_paddr (printable
representation of final address) as the failed address, and if the email
wasn't received thusly addressed, give q->q_alias->q_paddr (one step
back) as "expanded from". sendmail, however, records address expansion
*all the way back* to the one that was received via SMTP, as
q->q_alias->q_alias->q_paddr, q->q_alias->q_alias->q_alias->q_paddr,
etc.. (I know 'cause I patched X-Envelope-To: into sendmail, which
traces back through the entire chain to find that original address.)

Now, assumed that you're positive that backing out *just one* step
(where available) is going to reliably fix your problem, you could
change the source as follows (indentation reduced etc. to increase
readability):

From:
if (printheader)
{
putline("   ----- The following addresses [...]",
mci);
printheader = false;
}

(void) sm_strlcpy(buf, shortenstring(q->q_paddr, MAXSHORTSTR),
sizeof buf);
putline(buf, mci);
if (q->q_rstatus != NULL)
{
[...]
}
if (q->q_alias != NULL)
{
(void) sm_snprintf(buf, sizeof buf,
"    (expanded from: %s)",
shortenstring(q->q_alias->q_paddr,
MAXSHORTSTR));
putline(buf, mci);
}

Doing what:
-- Beefing up the sm_strlcpy() so that it will give the less expanded
address if available
-- Removing the (now useless) "if (q->q_alias != NULL)" part (that
used to create the "(expanded from: ...)" line)

To:
if (printheader)
{
putline("   ----- The following addresses [...]",
mci);
printheader = false;
}

(void) sm_strlcpy(buf, shortenstring(
( q->q_alias == NULL ? q->q_paddr : q->q_alias->q_paddr ),
MAXSHORTSTR),
sizeof buf);
putline(buf, mci);
if (q->q_rstatus != NULL)
{
[...]
}

Regards,
J. Bern

[ Post a follow-up to this message ]