From owner-freebsd-isp@FreeBSD.ORG Tue May 27 12:25:41 2003 Return-Path: Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 65C1637B404 for ; Tue, 27 May 2003 12:25:41 -0700 (PDT) Received: from pop016.verizon.net (pop016pub.verizon.net [206.46.170.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24ADA43FDD for ; Tue, 27 May 2003 12:25:39 -0700 (PDT) (envelope-from cswiger@mac.com) Received: from mac.com ([129.44.60.214]) by pop016.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030527192539.OBTY3199.pop016.verizon.net@mac.com> for ; Tue, 27 May 2003 14:25:39 -0500 Message-ID: <3ED3BBB2.5040506@mac.com> Date: Tue, 27 May 2003 15:25:38 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-isp@freebsd.org References: <004f01c32441$bbee0bc0$aa8ffea9@abyss> In-Reply-To: <004f01c32441$bbee0bc0$aa8ffea9@abyss> X-Enigmail-Version: 0.75.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at pop016.verizon.net from [129.44.60.214] at Tue, 27 May 2003 14:25:38 -0500 Subject: Re: Expiring old mail in Maildir/ X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2003 19:25:41 -0000 Troy Settle wrote: [ ... ] > Local delivery, remote delivery, who cares? People who administer mail servers care, or ought to. The single most common misconfiguration problem novice mail admins make when attempting to perform "virtual domains" is not identifying which addresses the server considers "local". > If you want to use sendmail as a point of reference, Sometimes I'm not sure that "what I want" has any relevance whatsoever, but on a good day I don't feel that way. > then yes, sendmail does handle local delivery. It does so with > exactly one delivery mechinism: the pipe. Either you're ignorant as to how sendmail actually works, or you are being intentionally deceptive. 12-sec% cd /usr/src/contrib/sendmail/src 13-sec% grep m_mailer deliver.c strcmp(m->m_mailer, "[IPC]") == 0 && if (strcmp(m->m_mailer, "[FILE]") == 0) if (strcmp(m->m_mailer, "[LPC]") == 0) else if (strcmp(m->m_mailer, "[IPC]") == 0) syserr("null destination for %s mailer", m->m_mailer); ret = safefile(m->m_mailer, getuid(), getgid(), m->m_mailer, sm_errstring(ret)); (void) execve(m->m_mailer, (ARGV_T) pv, syserr("Cannot exec %s", m->m_mailer); m->m_name, m->m_mailer); strcmp(m->m_mailer, "[IPC]") != 0 && if (strcmp(m->m_mailer, "[IPC]") != 0 || Sendmail does not use a pipe for the default [IPC] mailer; this either uses Unix domain sockets [makeconnection_ds()] or by opening a socket to the appropriate port on the remote mail server in daemon.c and speaking SMTP over a SOCK_STREAM. Sendmail does not use a pipe for the [FILE] mailer; the docs for mailfile() even indicate why: /* ** MAILFILE -- Send a message to a file. ** ** If the file has the set-user-ID/set-group-ID bits set, but NO ** execute bits, sendmail will try to become the owner of that file ** rather than the real user. Obviously, this only works if ** sendmail runs as root. ** ** This could be done as a subordinate mailer, except that it ** is used implicitly to save messages in ~/dead.letter. We ** view this as being sufficiently important as to include it ** here. For example, if the system is dying, we shouldn't have ** to create another process plus some pipes to save the message. For other mailers (except maybe [LPC]), sendmail does use a pipe to a child process. > I would argue that the MTA (mail transfer agent) has nothing at all to > do with SMTP (simple mail transfer protocol), I suppose that a network-capable mailer which did not do SMTP, perhaps a really old version of the DECnet mail software, is still an MTA, so I won't disagree. > [SMTP] which is simply a mechanism for clients to talk to servers and > for servers to talk to other servers. SMTP wasn't really intended as a mechanism for clients (*) to talk to servers; it's a mechanism for one mail server to exchange messages with another mail server over IPC. (*): The term "client" is overloaded here; if by client you meant "MUA", then clients talk IMAP or POP to mail servers to read mail, and often use SMTP to send mail, but MUAs can also send outgoing mail via MSP (587/tcp) or by calling the MTA directly via fork() as well. > What if I run sendmail in such a way that it's not listening for network > connections? Is it still an MTA? Yes. -- -Chuck