Hector Santos wrote:
MSA - Mail Submission Agent receiver with an authorized MUA
either with ESMTP AUTH, IP based, etc. MUA has a
relationship with the MSA network and is allowed to
send both local and/or routed mail.
Yes, we could just copy what 2476bis says for MUA / MSA / MTA.
MDA - Mail Destination Agent receiver for local users or
locally hosted domains. No authorization required but
it can not be used to relay mail.
In other words it's normally the MTA where the mail leaves SMTP
- we could exclude gateways like mail2news.
Sometimes folks talk about "MDA" as something that might decide
to forward (because it's actually the same box and smtpd). But
in that case it's acting as MTA (more precisely as a "mediator"
in Dave's mail-arch terminology).
No problem if the same box does different things, but as MDA
it delivers, period. While it does something else it also is
something else (conceptually).
in Dave's mail-arch that would be a "mediator".
Confusion Frank. :-)
There's no confusion, Dave's terminology is clear, and with
"mediator" he precisely got the 5.3.6(a) and 5.3.6(b) cases.
When John said "real relay" for his (3) it was unclear what
this might be, "relays" don't pop up from nowhere in a route,
they have a role.
Eventually I came to the conclusion that John's (3) is neither
a "mailout" nor an "open relay", it's not on the sending side,
it's the border MTA of the receiver (modulo 5.3.6), and in "my"
terminology that's an MX.
An open relay is legitimate MTA or badly configured MDA.
"MDAs" using your definition do not relay. If you add "bad" as
qualifier you could also say that a "badly configured MSA" can
be an open relay. Let's stick to the terms for agents working
as designed / defined.
I think you missed John's point.
That was impossible, his point was that SMTP restricted to its
own methods (never look into the DATA, pretend that BLs don't
exist, etc.) MUST favour accept + return, because then there
simply are not many reasons to reject left.
Overall, I think we need technical clarifications not Policy
clarifications.
Many admins still believe that the RfCs want and force them to
accept + return. The most stubborn even insist on "return" for
identified spam or worms - based on the correct idea that this
identification could be a false positive. That causes _harm_
and 2821bis must be clear that it's _wrong_ and not "required".
the system begins to breaks down with SMTP accept-->drop
Yes.
If this catches on, then we are in trouble.
s/If this catches on, then//
[...]
None of that stuff threatens the email infrastructure.
That's a contradiction. The "drop" is a consequence of "bogus
bounces to a forged MAIL FROM get me blacklisted". Bye, Frank