RE: [cobalt-users] Raq3 GUI forward mail doesn't forward cgi sendmail

["Colin J. Raven" <cjraven@xxxxxxxxxxx>]

<snippage>
>
> John doesn't want to possibly risk his password for the John account when
> checking his email so he has another account named Doe. Doe also
> resides on
> the same raq, but is in a different virtual site. Note the raq
> only has one
> ip address and several virtual domains.
>
> So John goes into his account through the gui and forwards his email to
> Doe@xxxxxxxxxx He then feels that he can check his mail using
> Doe@xxxxxxxxx
> without worry. He in fact gets all mail forwarded from John@xxxxxxxxx, but
> all of the sudden, he no longer gets any comments via the cgi
> script on his
> web site. So he ssh into his John account and checks the mail with pine.
>
> Lo and behold! John sees that there are a dozen or so emails from the cgi
> script waiting in his inbox. These messages, for some reason, are
> not being
> forwarded to his Doe account.
>
> Now why is that? Is this because the messages are being generated
> within the
> raq and therefore are not being processed via the cobalt gui? If so, what
> can I do to get the cgi messages to go to the Doe account without actually
> modifying the cgi script?

What I would do under comparable circumstances:- *don't* do it through the
GUI, do it via the CLI. Create a .forward file in John's home directory and
put one single line in it thusly:
doe@xxxxxxxxx

Previously I had often tried to get user's mail to fwd via the GUI and
roughly 50% of the time it would fail to save and fail therefore to forward.
(Qube2, RAQ2)Therefore I "gave up" on the idea some time back and reverted
to well understood and traditional methods.  Now if a user wants mail sent
onwards to xxx@xxxxxx it's either a procmail recipe (if there are
"conditions" associated with the forwarding) or else .forward if the request
is; "send *all* mail for me to this account [please]"

In fact candor compels me to say I quit trying to explain (to myself) the
*why* merely recognizing a familiar conclusion, that the CLI is (as is
overwhelmingly the case); "the better way" in the Cobalt world and
throughout all of Unix and Linux. Although understanding what the Cobalt GUI
will overwrite at the next reboot helps in deciding the approach!!!

I don't think this is any more or less of a bug than the confounding number
of other peculiarities that seem to afflict the Cobalt GUI. That said, the
boxes *are* marketed as a device that doesn't require CLI expertise, and can
be administered by a Linux novice. I have a problem with the concept, but it
seems to have worked in revenue terms for Cobalt/Sun.

Regards & HTH,
-Colin
--
Colin J. Raven