Forum OpenACS Development: Problems delivering mail due to invalid bounce email address

OpenACS creates by default custom bounce addresses in package acs-mail-lite.

ad_proc -public bounce_address {
} {
Composes a bounce address
@option user_id user_id of the mail recipient
@option package_id package_id of the mail sending package
(needed to call package-specific code to deal with bounces)
@option message_id message-id of the mail
@return bounce address
} {
return "[bounce_prefix]-$user_id-[ns_sha1 $message_id]-$package_id@[address_domain]"

Based on our experience, most mailers reject e-mails with a non-existing email address, since SPAM mails usually have an invalid bounce email:

localhost postfix/local[14071]: CD99CB8078: to=, relay=local, delay=0.48, delays=0.34/0.08/0/0.06, dsn=5.1.1, status=bounced (unknown user: "bounce-31300-a61ed9ca5c39b63ddf28c3862041d042bd73450a-21457"

To avoid this problem, we simply patched function "bounce_address" as follows:

RCS file: /home/cvsroot/acs-mail-lite/tcl/bounce-procs.tcl,v
retrieving revision 1.2
diff -r1.2 bounce-procs.tcl
< return "[bounce_prefix]-$user_id-[ns_sha1
> return ""

Is there anybody else experiencing this sort of issue?

Is there something that would speak against an acs-mail-lite parameter "BounceAddress" and the option to choose between a fixed bounce address and the legacy solution?



When reading the documentation of acs-mail-lite [1], doing so would break the bounce mail processing. acs-mail-lite seems to implement a scheme called VERP, which requires an adjusted mail configuration to accept such mails (see as well [1], there is more e.g. in [3]).

Can this be the problem on your configuration?

all the best


Hi Gustav,
thanks for pointing this out.

Such measure would indeed make the automatic handling of bounces impossible. Then again such feature is not required in all cases and an additional configuration option might eliminate some of the complexity of an initial mail set up.

Next time the issue comes up I'll play with the parameters to see if I can produce an "acceptable" sender address.
However, this seems to be only necessary in scenarios where

a) External Mail Providers have very rigid policies or
b) Company policies prevent changes in local mail server configurations

Thanks Gustaf - very accurate and helpful as always!


i have no experience with buunce mail processing, but as i understand it the intention of the modified sendmail file (on the site where OpenACS is running) is to allow the mangled email addresses. Point (a) should not be an issue, but point (b) certainly (if a user can run an OpenACS instance, but cannot not change the mail configuration, and/or is not allowed to run a mail server).

An option to deactivate automated bounce processing and using a fixed mail-bounce address make sense in such situations.