Mail delivery failed: returning message to sender

Mail Delivery System Mailer-Daemon at pop.de
Mon Aug 21 19:49:48 GMT 2000


This message was created automatically by mail delivery software.

A message that you sent could not be delivered to all of its recipients. The
following address(es) failed:

  tc-wedel.de!monscheu at s023250.tk.tc-wedel.de:
    SMTP error from remote mailer after RCPT TO:
    <tc-wedel.de!monscheu at s023250.tk.tc-wedel.de>:
    host 195.222.202.30 [195.222.202.30]:
    550 relaying to <tc-wedel.de!monscheu at s023250.tk.tc-wedel.de> prohibited by administrator

------ This is a copy of the message, including all the headers. ------

Return-path: <samba-ntdom at samba.org>
Received: from zwitter-nt.hamburg.pop.de ([192.168.1.3] helo=smtpshield.pop.de)
	by virus.pop.de with smtp (Exim 3.02 #1)
	id 13QxZs-0002zE-00
	for tc-wedel.de!monscheu at s023250.tk.tc-wedel.de; Mon, 21 Aug 2000 21:49:48 +0200
Received: FROM virus.pop.de BY smtpshield.pop.de ; Fri Aug 21 21:51:38 1998 +0100
Received: from [195.222.210.68] (helo=uucp.hamburg.pop.de)
	by virus.pop.de with esmtp (Exim 3.02 #1)
	id 13QxZr-0002zC-00
	for tc-wedel.de!monscheu at s023250.tk.tc-wedel.de; Mon, 21 Aug 2000 21:49:47 +0200
Received: from [203.17.0.92] (helo=samba.org)
	by uucp.hamburg.pop.de with esmtp (Exim 2.054 #1)
	id 13QxZl-0003Es-00
	for tc-wedel.de!monscheu at s023250.tk.tc-wedel.de; Mon, 21 Aug 2000 21:49:42 +0200
Received: from localhost ([127.0.0.1]:8403 "HELO ") by samba.org with SMTP
	id <S27806501AbQHUTvS>; Tue, 22 Aug 2000 05:51:18 +1000
Message-Id: <39A18748.73FC2556 at grainsystems.com>
Errors-To: listproc-errors at samba.org
Reply-To: kevinc at grainsystems.com
Originator: samba-ntdom at samba.org
Sender: samba-ntdom at samba.org
Precedence: bulk
From:   Kevin Colby <kevinc at grainsystems.com>
To:     Multiple recipients of list SAMBA-NTDOM <samba-ntdom at samba.org>
Subject: Re: SURS, machine accounts, etc... [wasRe: Inoltra: Re: Why machines in 
 passwd anyway?]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Listprocessor-Version: 6.0d -- ListProcessor by Anastasios Kotsikonas
X-URL:  http://lists.samba.org/
X-Comment: Discussion of NT domain controller support in Samba
References: <200008141619.SAA00559 at mister.cdc.polimi.it> <14753.28129.602007.94686 at wire.cadcamlab.org>
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
Date:   Tue, 22 Aug 2000 05:51:18 +1000


I have to agree with Peter.  Keeping workstations in /etc/passwd
is as bad as the "long filename support" in Windows.  It is an abuse
of existing systems to accomplish something that would otherwise
require some fundamental rethinking.  IMHO, the fact that doing this
right would be harder doesn't make this any less wrong.

Admittedly, I do not have a fix in hand, and I do not wish to bash
the current development or developers at all.  If I can get some
time for this, I will look into it more deeply myself.  Elrond's
comments do raise some issues.  However convenient it might be, the
system user list is not Samba's personal storage area, and I feel
compelled to voice my support for a better approach.

Unfortunately, I missed the SURS debate on samba-technical.
I am trying to find it now.  Are there any other points on SURS
and this or any documentation?  What are the "new techniques"
that TNG should use for SURS?

	- Kevin Colby
	  kevinc at grainsystems.com



Peter Samuelson wrote:
> 
> [Gerald Carter <gcarter at valinux.com>]
> > Could someone give me a one line summary of why machine accounts in
> > /etc/passwd is a bad thing.  Other than it looks messy.
> 
> I've got three reasons.
> 
> 1. It looks messy.  Oh wait, that doesn't count. (:
> 
> 2. Conceptually it's superfluous.  The point of the password file is to
>    hold information about users, UID, GID, etc -- enough information to
>    authenticate a user and associate with him a security context.  The
>    system accounts (daemon, bin, uucp) are useful even without
>    passwords because they give us a UID and default GID.  NT trust
>    accounts are not useful for anything -- except as a list.  The UID
>    isn't used.  The GID isn't used.  The home directory isn't used.
>    Nothing is used except the name itself, and that's what you looked
>    up.  So why?
> 
>    Yes, I've been told we also use the UID to calculate a RID.  To me
>    that's the wrong approach.  Simo Sorce's patch to put the RID
>    directly in smbpasswd seems to me at once more sensible and more
>    efficient.  Efficient because it means in some cases we may not have
>    to look up the passwd file entry at all; sensible because the RID is
>    a property useless outside the Samba subsystem, so why not store it
>    in a file used only by Samba?
> 
>    I still don't understand the problem with the RID-in-smbpasswd
>    approach.  I know Elrond tried to explain it once -- maybe I'll go
>    back and reread that message.
> 
> 3. Name length limitations.  Some Unices (AIX is one) can't make use of
>    usernames longer than 8 characters.  That means domain members
>    cannot be longer than 7 chars, thanks to the trailing '$'.
> 
> Peter




More information about the samba-ntdom mailing list