Re: [cobalt-users] Create email user account or even alias onlywithout web directory, etc?

[flash22@xxxxxxx]

On Mon, 3 Sep 2001, Jeff Lasman wrote:

> flash22@xxxxxxx wrote:
> 
> > > Any manual config file edit that will allow me to do this?
> > 
> > no, because forwarding to outside domains is handled in two steps, map
> > from alias to username via virtusertable, followed by map from username to
> > externam address vis aliases, if you don't have a real username inbetween
> > , sendmail will get upset (they way it's configured on the raq's)
> 
> Actually it's easy; I just haven't had time to write it up this weekend
> <frown>.

Well what have you been doing all weekend <ducking>

> 
> You create your own aliases file (I call my aliases.local) and make a
> small change to sendmail.cf to use it.
> 
> To the bottom of virtusertable you add "domainuser@xxxxxxxxxx" pointing
> to "useralias" (the "useralias" must NOT be a username on the RaQ). 
> Then in aliases.local point "useralias" to the address you want to send
> it to.

Well, creating your own private alias list kinda counts as reconfiguring
it, i was assuming he wanted a way to do it without unvirginifying the
machine ;0

> 
> This is the RIGHT way to do this; why would you want to use up resources
> on your RaQ to create users for people who only need email forwarding?

The only catch is since the GUI doesn't know those usernames have been
used, you could accidently create that username later....minor i suppose

Still, post it sometime, It's a nice hack :)
> 
> You've seen all those ads from web-hosting companies offering unlimited
> forwards, haven't you?  You really didn't think they actually set up
> thousands of users on their boxes, did you?

Yes, and i have never really understood why cobalt did it the way they
did, since creating a user also gives all kinds of potential access that
is usually totally unneeded...

But then, i could go on and on about lack of full virtualization in the
user@domain list also, this has been possible for sendmail/qpop for 
rather a while now....

> Nothing worse than if you had a user on the box.  Either way, user or
> not, the email will eventually be returned to the original sender
> (return path).

I was thinking SPAM here,aka forged return path's, i get really nifty
bounces from silly spammers,
they occasionally end up in the user mailbox ....(bug?)

gsh