----- Original Message -----
From: "Frank Ellermann" <nobody(_at_)xyzzy(_dot_)claranet(_dot_)de>
Before going into the details: could we add some common
definitions for MSA and MDA to 2821bis ?
I think this would be useful.
I think the common topology understanding has been:
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.
MDA - Mail Destination Agent receiver for local users or locally
hosted domains. No authorization required but
it can not be used to relay mail.
The key difference Frank is that the sender is authorized in
the MSA transaction and for MDA the sender does not require
authorization.
MTA - Mail Transfer Agent which is basically the part of
of the MUA and/or router/relay that is sending mail.
I believe I have seen MTA described (forums and literal) to also include
general receivers too, with specifics being MSA, MDA. Technically correct,
however, it does have confusion when describing transaction directions. I
personally like to use MTA to mean "router/sender or client."
Okay, in the most simple case (3) is a "mailout" behind (2),
the "border MTA" of the sending side (1+2+3).
Or it's some kind of "redistributor" (mailing list), or any
"forwarder, in Dave's mail-arch that would be a "mediator".
Confusion Frank. :-)
Or it's an "open relay". I don't care much about open relays,
but we can neither forbid nor ignore them. Not in 2821bis.
An open relay is legitimate MTA or badly configured MDA.
Open relay simply means no "checking" or authorization is done
on the client.
That could eliminate the "mediator" cases, a "mediator" does
something, e.g. modify the RCPT TO. OTOH the RCPT TO isn't
in the content, it's in the envelope... probably you don't
want to eliminate the "mediator at (3)" case here for this
scenario (?)
Mediator? More confusion.
Frank, I could be wrong, but I think you missed John's point.
Overall, I think we need technical clarifications not Policy
clarifications. There is simply too much involved when describing
policy.
To me, SMTP is a black and white protocol. No middle ground.
- SMTP Reject
- SMTP Accept -> bounce/forward
No inbetweens.
While local policies might detect the above behavior, nevertheless, it is
the limited behavior protocol.
The concerns are how much "policy" or "world events" s beginning to change
the above protocol it into:
- SMTP Reject (for extremely wrong reasons)
- SMTP Accept -> bounce/forward/DROP
The first is not so terrible because of the inherent SMTP engine allows for
retries.
However, the system begins to breaks down with SMTP accept-->drop
and what has concerned me over the years as how this is becomming more
policy driven than actual software driven.
It was a slow pace concern over the years because for the most part you only
see this level of irresponsible and/or poor level of operation with your
smaller, home brew system. It is not a issue with larger systems, however,
I am afraid that we are beginning to see larger systems, in the name of
spam, using poor ideas and reasoning beginning to do "accept-->drop"
behavior. If this catches on, then we are in trouble.
I saw this with Microsoft and hotmail.com when they started SenderID
implementation. The big change here is not senderid itself but its
reliance on STRONG 2822 headers on the payload.
The big change is this:
Most systems will ACCEPT a payload with no headers and use the envelope to
create x822 headers. Thats the common behavior and most SMTP systems follow
this.
Hotmail.com will no longer accept a payload with a 2822 header.
I am not sure if this is a big concern or not. But it is a new radical
change and it raises the question if the PAYLOAD should have a 2822 header
or not.
Thinking about this for our own system. I think a large part of the answer
is that it depends on the # of hops. If its a router, then it must have a
2822 header. If not, then its not required.
The point is that a Received must be present for a router.
Anyway, this is the level of issues I am particularly more interested in
resolving for the future of SMTP. "Mediator" or non-priority issues of
whether the BOUNCE term should be deprecated is not a concern to me,
atleast, I don't see it. None of that stuff threatens the email
infrastructure.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com