[Top] [All Lists]

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

2012-08-29 03:07:13
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 

     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).

ietf-smtp mailing list

<Prev in Thread] Current Thread [Next in Thread>
  • [ietf-smtp] MTA vs MDA, was [sbfbis] Authentication-Result (Issue 10?), Alessandro Vesely <=