Subject: [ietf-smtp] MTA vs MDA, was [sbfbis] Authentication-Result (Issue 10?)

From: Alessandro Vesely <[email-masked]>
Date: Wed, 29 Aug 2012 10:06:35 +0200

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