I've read the sendmail bat book, and I still don't understand how the
bounce mechanism works. It seems that the built-in error delivery
agent can be used to generate a bounce. But I don't see any reference
in sendmail.cf to the following message:
550 5.1.1 foobar... User unknown

Nor does Rule testing give the expected results:
[root@mail content]# /usr/sbin/sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> 3,0 foobar
...
parse returns: $# local $: foobar

I might conclude that the delivery agent triggers the bounce. But I've
never seen this defined as part of the Delivery Agent specification.

I'm eager to learn more about this, so links to additional
documentation will be very much appreciated.

Thanks,

Jim Schueler
Motor City Interactive

In article <1158674372.273496.75390@h48g2000cwc.googlegroups. com>
"gymshoes" <jschueler@tqis.com> writes:
>I've read the sendmail bat book, and I still don't understand how the
>bounce mechanism works. It seems that the built-in error delivery
>agent can be used to generate a bounce. But I don't see any reference
>in sendmail.cf to the following message:
> 550 5.1.1 foobar... User unknown
>
>Nor does Rule testing give the expected results:
> [root@mail content]# /usr/sbin/sendmail -bt
> ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
> Enter <ruleset> <address>
> > 3,0 foobar
> ...
> parse returns: $# local $: foobar

This check (normally) happens internally in sendmail, based on the
presence of the 'w' flag in the mailer definition - from doc/op/op.*:

w The user must have a valid account on this
machine, i.e., getpwnam must succeed. If not, the
mail is bounced. See also the MailBoxDatabase
option. This is required to get ".forward" capa-
bility.

Basically sendmail does a getpwnam() on the recipient name.

>I might conclude that the delivery agent triggers the bounce. But I've
>never seen this defined as part of the Delivery Agent specification.

You've seen a Delivery Agent specification? Where?:-) Anyway, it's
certainly conceivable for the delivery agent to generate and send a
*bounce* of its own, after all it's just another e-mail message - though
better would be for it to tell sendmail to do it by means of a non-zero
exit code, e.g. for this case (from sysexits.h):

#define EX_NOUSER 67 /* addressee unknown */

However leaving the decision to the delivery agent (via either of the
two alternatives above) is undesirable in the spam era, precisely
because it entails the sending of a bounce - the standard method of
having sendmail check internally, as well as any check implemented in
the rulesets, has the advantage of causing a rejection of the recipient
already in the SMTP dialogue.

--Per Hedeland
per@hedeland.org

Thanks Per.

I appreciate that mail operations should use an RFC 821 error message
instead of sending bounces. So I expected better documentation and
more interest in my post.

As soon as the Recipient is specified in the SMTP dialog, sendmail must
run through Ruleset 0 to determine by the mailer whether the w option
is invoked. If the fork and exec operations also occur at this point,
then a delivery agent exit code could trigger an RFC 821 message... if
it exits immediately. This solution is more practical than generating
the error within the rulesets.
However sendmail would have to handle an exit code differently
depending on when the agent exits.

Your response suggests otherwise. Is it worth the effort for me to
test my theory?

Thanks,
-Jim

Per Hedeland wrote:
> In article <1158674372.273496.75390@h48g2000cwc.googlegroups. com>
> "gymshoes" <jschueler@tqis.com> writes:
> >I've read the sendmail bat book, and I still don't understand how the
> >bounce mechanism works. It seems that the built-in error delivery
> >agent can be used to generate a bounce. But I don't see any reference
> >in sendmail.cf to the following message:
> > 550 5.1.1 foobar... User unknown
> >
> >Nor does Rule testing give the expected results:
> > [root@mail content]# /usr/sbin/sendmail -bt
> > ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
> > Enter <ruleset> <address>
> > > 3,0 foobar
> > ...
> > parse returns: $# local $: foobar
>
> This check (normally) happens internally in sendmail, based on the
> presence of the 'w' flag in the mailer definition - from doc/op/op.*:
>
> w The user must have a valid account on this
> machine, i.e., getpwnam must succeed. If not, the
> mail is bounced. See also the MailBoxDatabase
> option. This is required to get ".forward" capa-
> bility.
>
> Basically sendmail does a getpwnam() on the recipient name.
>
> >I might conclude that the delivery agent triggers the bounce. But I've
> >never seen this defined as part of the Delivery Agent specification.
>
> You've seen a Delivery Agent specification? Where?:-) Anyway, it's
> certainly conceivable for the delivery agent to generate and send a
> *bounce* of its own, after all it's just another e-mail message - though
> better would be for it to tell sendmail to do it by means of a non-zero
> exit code, e.g. for this case (from sysexits.h):
>
> #define EX_NOUSER 67 /* addressee unknown */
>
> However leaving the decision to the delivery agent (via either of the
> two alternatives above) is undesirable in the spam era, precisely
> because it entails the sending of a bounce - the standard method of
> having sendmail check internally, as well as any check implemented in
> the rulesets, has the advantage of causing a rejection of the recipient
> already in the SMTP dialogue.
>
> --Per Hedeland
> per@hedeland.org

In article <1158844382.708423.297310@h48g2000cwc.googlegroups .com>
"gymshoes" <jschueler@tqis.com> writes:
>
>As soon as the Recipient is specified in the SMTP dialog, sendmail must
>run through Ruleset 0 to determine by the mailer whether the w option
>is invoked. If the fork and exec operations also occur at this point,
>then a delivery agent exit code could trigger an RFC 821 message... if
>it exits immediately.

Well, it doesn't happen that way - sendmail doesn't invoke the delivery
agent until the SMTP transaction has been completed. Doing otherwise
would require a more sophisticated interface than the current
"specification" (i.e. recipients on commandline, message on stdin, give
exit code when delivery completed). E.g. the client may not complete (or
even arrive at) the DATA phase, in which case no message must be
delivered - but there is no way for sendmail to tell the delivery agent
to abort. (There are other issues too, like wanting to take advantage of
the delivery agent's capability to deliver to multiple recipients in one
go.)

Of course a "more sophisticated interface" does exist, i.e. LMTP, and
sendmail does support it - but using it doesn't actually change any of
the above.

>Your response suggests otherwise. Is it worth the effort for me to
>test my theory?

Uh, if your theory is that sendmail invokes the delivery agent during
the SMTP dialogue, no, it's not worth the effort to test that, since it
isn't true.:-) Of course you don't need to take my word for that, but
then there's no point in asking for my opinion on the effort either.:-)

--Per Hedeland
per@hedeland.org