From vesely@tana.it Wed Aug 29 01:07:07 2012 Return-Path: X-Original-To: ietf-smtp@ietfa.amsl.com Delivered-To: ietf-smtp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCCDD21F84A7 for ; Wed, 29 Aug 2012 01:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.269 X-Spam-Level: X-Spam-Status: No, score=-4.269 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqPO0GLexQrY for ; Wed, 29 Aug 2012 01:07:07 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF8521F84A5 for ; Wed, 29 Aug 2012 01:07:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1346227619; bh=NxvL+VKpH7LvuHwMrCUbhooe4MV1qSqx0vu6ar7mXEU=; l=2992; h=Message-ID:Date:From:MIME-Version:To:CC:References:In-Reply-To: Content-Transfer-Encoding; b=XLkb/e5Tkbb1RAXj13QOMoZrUXO9mRYm8zRMQ9w/+3jBOK0u0tMpRi+nZHEXQ1HXY F0DW9BeJPrbVDO2x2skz+JGnDlToLY7Qo6lZ9obCKY4LAILya3Nmr8hh+iflwnx54F zRx70tfu+Eg/m4v0ZvyiI9lss0x9l659hcNuuGcE= Received: from [37.183.70.243] ([37.183.70.243]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 29 Aug 2012 10:06:53 +0200 id 00000000005DC035.00000000503DCD9F.00001C9A Message-ID: <503DCD8B.8000306@tana.it> Date: Wed, 29 Aug 2012 10:06:35 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Hector Santos References: <2038344.xmME5XhsPg@scott-latitude-e6320> <20120826185557.36239.qmail@joyce.lan> <503B438A.8080203@tana.it> <503B8AC8.8080009@tana.it> <503C8690.1030004@tana.it> <503D03FE.5010507@isdg.net> In-Reply-To: <503D03FE.5010507@isdg.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "Murray S. Kucherawy" , ietf-smtp@ietf.org Subject: [ietf-smtp] MTA vs MDA, was [sbfbis] Authentication-Result (Issue 10?) X-BeenThere: ietf-smtp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 08:07:07 -0000 I switch list and change subject. On Tue 28/Aug/2012 19:46:38 +0200 Hector Santos wrote: > > An SMTP code can have multiple roles, MTA, MDA and MSA and not to go > overboard and for the sake of simplicity a good way to see it is: > > MTA - generic transporter, router, sender/receiver, client/server, > etc. In general and traditionally, little to no overhead and > all "intelligent processing" was done post acceptance - Store > and forward. > > MDA - receiver with no authorization requirement (no open relay) > and only for local user or locally hosted domains. > > MSA - receiver with authorization requirement. Perhaps it's me, but while MTA and MSA are quite similar servers, I view an MDA as a sort of MTA add-on, a piece of software that takes care to save messages so that they are accessible to the end user. An MDA does not listen on a (well known) port, possibly except LMTP. > In older established systems, where the MTA did not have dynamic state machine processing, shims, hooks, i.e. ACLs, milters, WCX scripts for us, etc, the MDA was generally a gateway, mail importer/exporter, transformer, even uucp/slip processor, etc. This is where the email to user account existence check was done and this is where the bounce was also created (hence accept+bounce problems). > > But in modern systems, the MTA with user checking (delivery and user account checking), and state machine hook processing, it now behaves more like an MDA when there is no authentication for relaying. If there was authentication established, the user/sender account was checked etc, then its mode is behaving more like an MSA. > > Of course, there are still large scale systems that still keep these roles separated yet, increasingly to improve TCO, they are scaling up with lesser machines, more multi-cores machine and upgrading and updating the software so that a MTA can play more than one role. > > With RFC5598, the one noted objection I had with it during the development was its locked down on using SIEVE and at the time, and maybe still today, it only allowed for post SMTP processing. It could not be used as a inline SMTP state machine scripting tool to make dynamic decisions on the fly and this is where reality does include such modes with all the different SMTP software. It didn't support DNS lookups for example, to do the sort of SPF and/or other dynamic SMTP online checking. > > I believe RFC4408 has SPF as a SMTP level processor. If the target is a remote address, then we have a relay authentication requirement and SPF is not required. This would be the behavior of a MSA or MTA with relay authentication established. Hence, IMV, SPF is more of a MTA to MDA protocol because > A) No authentication is required to deliver mail, > b) No User Login is required, > c) Only mail for local user or locally hosted domain is allowed. > > Thats the behavior of a MDA. MTAs behave the same, except that open relays differ on (c). Ciao Ale