[Building Sakai] mailarchive / james rejected email notices not being sent

[Kevin Carruth]

We've recently noticed that when incoming emails are rejected by sakai, 
the original senders are not being notified by sakai's internal mailer. 
We're seeing this in two cases:
   1) a user sends mail to a site for which he does not have permission
   2) a user sends mail to a non-existent (bogus) site email address

In case #1, tomcat logs an exception like this:
==========
2012-01-09 11:18:28,630 INFO Spool Thread #9 
org.sakaiproject.james.SakaiMailet - : mail rejected: from: 
kcarruth at gmail.com not authorized for site: mdstfaculty
==========

In case #2, the log shows something like this:
==========
2012-01-09 11:20:14,477 INFO Spool Thread #6 
org.sakaiproject.james.SakaiMailet - <4F0B13BD.2080606 at virginia.edu> : 
mail rejected: org.sakaiproject.exception.IdUnusedException id=bogus-address
==========

In either case, the user who sent the message sees nothing in response, 
no indication that something went wrong. James does seem to create 
rejection emails but then for some reason doesn't send them. Pairs of 
files are created in

/usr/local/tomcat/webapps/sakai-mailarchive-james/apps/james/var/mail/address-error

One file will be named "<identifier>.Repository.FileObjectStore", and 
the other "<identifier>.Repository.FileStreamStore". For example, I just 
generated a pair by sending to a bogus address:
     4D61696C313332373432373733363435372D32333437.Repository.FileObjectStore
     4D61696C313332373432373733363435372D32333437.Repository.FileStreamStore

The 'FileStreamStore' file is a simple copy of the email sent, with 
headers and whatnot. The 'FileObjectStore' file is a binary file but 
when I read it, I can see some strings that would suggest its intent to 
be a rejection reply to the message sent in.

I found https://jira.sakaiproject.org/browse/SAK-19841 , which suggests 
that this functionality changed in 2.6 to prevent spam relaying, and a 
user suggests a possible 'fix' by registering the machine's actual IP 
address (instead of the default 127.0.0.1 that's already there) in a 
mailarchive config.xml file under "RemoteAddrNotInNetwork", but that 
hasn't worked for us. It's also been suggested using 
"authorizedAddresses" config in the same xml file, but that hasn't 
worked either. We've tried both specific IP addresses and wildcard 
catch-alls.

Has anyone had any success re-enabling these sorts of notifications in 
another manner, and if so, how?

Thanks,
Kevin @ UVa