Hector Santos <hsantos(_at_)santronics(_dot_)com> wrote:
This is basically one of the points I tried to make in my LMAP
Validation analysis; how results change when the examination includes
knowledge about RCPT. It is based on a traditional BCP operation
for SMTP:
- anonymous access can only send final destination or hosted domains
transactions
- Trust is required for routing/relay.
This is one way of stating a nearly universal practice of MTAs
which serve as both receivers and senders: A local authenticated user
may send anywhere, and mail from anywhere may be delivered locally.
Anything elses is likely to be rejected with "We do not relay".
(IMHO, this is a good practice, for those that practice it. Whether
it can be expanded beyond those that currently practice it is unclear.)
I poised some questions to John Klensin...
Here is some of his answers. This is not a knock, but just to
illustrate we have some real philosophical conflicts to be resolved.
I'm not sure "philosophical conflicts" can be resolved; but I agree
they should be understood -- otherwise our documents are likely to
mean different things to different people.
HS> In general, SMTP says that for final destination mail, anonymous
access is allowed (authentication is not required) and for
relaying, authentication or some trusted relationship *SHOULD*
be established.
John: Says where?
This certainly isn't in John Klensin's RFC2821 or RFC2822. If
Hector wants a capital-SHOULD, it needs to find a home in some RFC.
HS> In general, that trust is gained with:
- Sender IP is part of Receiver network ip domain
John: Maybe. This is considered a weak test, not much better than
simply using a receiver (target)-supplied MX chain, which
covers most of the cases in which relaying occurs these days.
There may be a misunderstanding. Hector is describing the locally
authenticated user, just assuming that the routing of that IP is
sufficient authentication. This is often true.
However, Hector did not _exclude_ the case where routing is _not_
sufficient authentication, which appears to be John's point.
HS> - allow relay IP tables
John: Not covered by any standard
These are less common, and John is correct.
HS> - POP3 before SMTP
John: Not a mechanism applicable to relays -- and one that causes
other problems.
Indeed, POP-before-SMTP is useless for accepting email forced to
go through an intermediary MTA. Nonetheless, it _is_ widely used.
There may even be a way to expand upon this idea so as to be useful
when MTA relays are involved: but most of us aren't expecting that.
HS> - ESMTP AUTH
John: yes
A clearly better solution than POP-before-SMTP.
HS> In a multi-hop situation, where there is a route between two
MTAs, I have always presumed a trust was established with
these non-MUA transactions. In other words:
MUA -----> MTA1 ----> MTA2 ---> MTA3 (Final Destination)
MUA is required to authenticate with MTA1 in order to relay
mail. Right?
John: nope
John is correct. There is no requirement, and seldom any test
beyond considering MUA to be "local" based on IP address.
[Hector's comment today: This threw me for a spin. I don't think
we can solve anything if we can't establish a trust system with
routes. Maybe he meant it wasn't a requirement, but that's one of
the issues we need to get cleared, because LMAP will be dependent
on this trusted route premise, otherwise it simply will never work
(can't be trusted).]
To the extent MTA1 "trusts" MUA based on IP address alone, it
can be defined to be sufficient trust.
We should, IMHO, feel free to _recommend_ SMTP-AUTH here, but
we certainly cannot _require_ it.
HS> MTA2 does not require authenticate with MTA3 because it is a
final destination transaction. Right?
But what about the transaction between MTA1 and MTA2?
Can I safely assume that there is a TRUST established here?
John: Nope, not in the general, or most other, cases.
Certainly not in the "general" case. But in several classes of
cases, there is an implied trust; and in others, MTA1 is delivering
to the recipient's agent based upon MX records. IMHO, whether to
call that "trust" is not a helpful question.
[Hector comment today: Again, this threw me for a spin. When I
see this type of thinking, it just makes you wonder how can anything
be done to correct the anonymous access problem.]
In <mxcomp> we are discussing how:
"
" those maintaining domains and networks [may]
" specify that individual hosts or nodes are authorized to act as
" MTAs for messages sent from those domains or networks.
The semantics of such specifications are not yet established. I
quite agree with Dave Crocker that discussing them would be helpful.
HS> Of course, I am not considering the situation where there is a
"broken" open relay or proxy, but under legitimate operations,
can I safely assume that all transactions between two non-MUA
routers are trusted?
John: Trust is in the mind of the beholder. But, generally, no.
This doesn't _necessarily_ mean that mxcomp can do nothing to
clarify "trust"...
Hector's comment today:
Again, this threw me for a spin. I think I understand what he is
basically saying, but I firmly believe we have some fundamental
mail transport design and operational concepts that needs to be
resolved.
I doubt we can do much of that here.
Before anyone can even begin to programmatically add logic to
software to examine the protocol level envelope to determine what
they mean, we first need to know how the topology of the mail
transport system is suppose to work.
The topology is simple: any two machines at the edge can establish
a SMTP session. Period.
We need some fundamental ground rules, baselines and/or SMTP
principles established and I think the best way to do that is to
study how the current systems behavior.
Many of us have done that already.
Anyway, my intent in the questions to John as it relates to LMAP is
that I can in no way see LMAP work if trust can not be established
at the point of message submission. This is a fundamental principle
that needs to be confirmed by everyone.
There is no such thing as a "fundamental principle that needs to
be confirmed by everyone". If you can't wrap your mind around that,
you don't belong here. Here, we believe in rough consensus and
running code.
At the final destination, LMAP presumes that the MAIL was submitted
with trust and if applicable, it was routed with trust. If that
"trust chain" is broken, then the final destination transaction is
invalid.
You're free to configure your MTA on that belief. Others are free
not to.
So how can this be programmatically validated? I don't see how can
it can validated without seeing the mail headers. The mail headers
will provide some level of validation based on the # of hops. Again,
LMAP can only work if the "trust chain" is consistent.
We're not here to validate "LMAP" (whatever that may mean). Live
with it. Read the charter!
I have many thoughts on this, but it always boils down to the
ultimate question of how much do we want to change SMTP to address
this.
Very little.
After all my research and work, and see what's out there, I can only
conclude that ultimately, to ideally address this entire issue, we
will need to expand the envelope to provide more information (i,e,
ESMTP extension to split the DATA command to HEAD + BODY).
That's an interesting idea. I almost wish it weren't off-topic.
--
John Leslie <john(_at_)jlc(_dot_)net>