ietf-mxcomp
[Top] [All Lists]

Re: Intermediate MTA setting MAIL-From

2004-03-23 06:50:39

Does it make sense to view this as a technical behavioral issue, rather than
philosophical first?

Maybe it is worth while if we examine and measure how systems behave
currently in regards to HELO, MAIL FROM, including RCPT, as well as the mail
content (headers).

This will give us a good premise to work with and some current practice
issues to discuss the ideals.  It will also allow us to measure how the
effect of change on these systems.

Example:

We ask how "human logic" will examine the MAIL FROM.  Well, many of those
examinations can be assisted by knowing other factors such as RCPT or even
the mail content.   For our particular system, it will not make any decision
on HELO/MAIL FROM until RCPT is known.  This logic is based on a RFC 2821
recommendation.  I am not saying that all systems should be operate this
way.  But we do it because the correctness of MAIL FROM is helped by knowing
some level of intent of the sender.  I am pointing out that a system might
benefit by naturally behaving as you might think a might human today when
some unknown person knocks on the door and rings your phone:

Ring ring....Caller Id is shown on phone

Receiver does not recognize the caller id, answered it.

Receiver:   Hello?
Caller:  Is Tom There?
Receiver:  Sorry, wrong number.
Caller:  Ok, sorry, bye.
<click>

Of course, there are other realistic scenarios (a public house) where the
receiver may or may not know if Tom exist.

On a related note:

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.

I poised some questions to John Klensin (incidentally, what does he have to
say about all this?) in an attempt to get a feel about the routed trust
behavior from his point of view.   Here is some of his answers.  This is not
a knock, but just to illustrate we have some real philosophical conflicts to
be resolved.

Response from John to Hector's "Simple Questions about Multi-Hop Routing:"

HS> In general,  SMTP says that for final destination mail, anonymous access
is allowed (authentication is not required)
HS> and for relaying, authentication or some trusted relationship *SHOULD*
be established.

John: Says where?

HS> In general, that trust is gained with:
HS>
HS>     - 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.

HS>     - allow relay IP tables

John: Not covered by any standard

HS>     - POP3 before SMTP

John: Not a mechanism applicable to relays -- and one that causes
other problems.

HS>     - ESMTP AUTH

John: yes

HS> In a multi-hop situation, where there is a route between two
HS> MTAs,   I have always presumed a trust was established with
HS> these non-MUA transactions.  In other words:
HS>
HS>   MUA  ----->  MTA1 ---->  MTA2  ---> MTA3 (Final Destination)
HS>
HS> MUA is required to authenticate with MTA1 in order to relay
HS> mail.  Right?

John: nope

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

HS> MTA2 does not require authenticate with MTA3 because it is a
HS> final destination transaction.  Right?
HS>
HS> But what about the transaction between MTA1 and MTA2?
HS>
HS> Can I safely assume that there is a TRUST established here?

John: Nope, not in the general, or most other, cases.

[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.]

HS> Of course, I am not considering the situation where there is a
HS> "broken" open relay or proxy, but under legitimate operations,
HS> can I safely assume that all transactions between two non-MUA
HS> routers are trusted?

John: Trust is in the mind of the beholder.  But, generally, no.

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.

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.

In my view, if the above two basic principles of BCP SMTP operations can not
be agreed upon as a standard requirement for the new era of trusted
operations, I honestly don't see how anything can be accomplished or solved
with reliability.

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.

I can begin this by saying that "today," most systems see a MTA receiver who
allows anonymous access routes as a Open Relay and will be an instant
candidate for blacklisting.  If this is a problem for some people here
helping to mold the outcome, then we got some major issues to work out.

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

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.

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.   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).   If we are concern about the Microsoft and Yahoo's
pushing the issue of requiring systems to accept mail before any trust logic
can be applied, then maybe ESMTP needs to begin preparing for the
inevitable.


-- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com






----- Original Message ----- 
From: "Dave Crocker" <dhc(_at_)dcrocker(_dot_)net>
To: "Jon Kyme" <jrk(_at_)merseymail(_dot_)com>
Cc: "Dave Crocker" <dhc(_at_)dcrocker(_dot_)net>; 
<ietf-mxcomp(_at_)imc(_dot_)org>
Sent: Tuesday, March 23, 2004 3:52 AM
Subject: Re: Intermediate MTA setting MAIL-From



Jon,

Who has authority to set the mailfrom?  If more than one entity has the
authority, what is the relationship among them?

If we validate that the field is authentic, what good is that? What will
be better?  What will not be changed?

d/


JK> Dave, I'm not sure what you mean by

That is why we need to be clear about the lines of authority for
setting
values. As a practical matter, I view MailFrom as being under the
authority of the entity referenced in the RFC2822 Sender field.



JK> Surely (2822)Sender should only be there in particular circumstances
JK> (i.e. not always).



d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>