🚀 go-pugleaf

What's going on here is a mismatch between the way AMS runs with and
without AMDS (the AMS Delivery system, useful only if you have the
Andrew File System).    Not surprisingly, the mechanisms were optimized
for the AMDS environment; I have found it possible to make them work,
albeit with a few oddities, in a non-AMDS environment.

First, you have to understand a wee bit about the process of AMS address
validation.  If you put a bboard name on a To: or CC: line in
sendmessage, this will get transformed into a posting address according
to the proper .MS.DirectPost file.  All this stuff works just fine.  The
oddity only begins to happen if your direct post file sends stuff back
to a "local" user -- e.g. your bboard account.

In that case, what happens under various circumstances is that the
address can get RE-validated.  That is, the output of the validation
process becomes the input for another validation process.  This turns
out to be fine in AMDS-style bboards, where the "local" address  is
something like "bb+bboard-name", because the software knows that the
+suffix is something important and to be preserved.  However, in
non-AMDS situations, we typically run a bboard system with posting
addresses like

"bb+foobar" <bb@mysite>

Unfortunately -- and I guess this could be considered a bug to be
patched, ITC people -- the validation software considers the route
phrase "bb+foobar" to be something it can safely throw away.  

Fortunately, there is a workaround.  Just use a posting address that
doesn't precisely match your local value of ThisDomain.  For example, at
Bellcore ThisDomain is "thumper.bellcore.com".  This means that I might
have problems if I put either of the following in my .MS.DirectPost file:

"bb+foobar" <bb>
"bb+foobar" <bb@thumper.bellcore.com"

However, the trick I use is to use a host name that AMS doesn't think of
as local, but that sendmail does.  In my case, my .MS.DirectPost files
read more like

"bb+foobar" <bb@thumper>

This is validated as an external address, and hence not rewritten at all
-- just what the doctor ordered!

So, the bottom line is:  there is a bug in validation in that it throws
away route phrases (and comments!) in local RFC822 addresses when it
validates them.  This should be fixed, but meanwhile the workaround is
to set up your .MS.DirectPost files so that they don't look like "local"
addresses, which you can do by using some alias for your local host name.

Hope that's helpful and clarifying.  -- Nathaniel