Subject: TECH ERROR: ietf-marid-core - problems with MUA determenining PRA

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 27 Aug 2004 09:27:31 -0700 (PDT)

In section 2.1 it is written that:
   (*1*)
  "As seen from the question, this mechanism applies to unrelated
   parties:  it is useful at the point where a message passes across the
   Internet from one organization to another.  It is beyond the scope of
   this document to describe authentication mechanisms that can be
   deployed within an organization."

Clearly the distinction is made that the mechanisms of MARID athentication 
and determining PRA should only be performed on the network boundaries 
during SMTP transmission between different ISPs and not within the same 
network. But previously in section 1 it states that:
  (*2*)
  "This document describes a mechanism such that receiving MTAs, MDAs
   and/or MUAs can recognize mail in the above category and take
   appropriate action.  For example, an MTA might refuse to accept a
   message, an MDA might discard a message rather than placing it into a
   mailbox, and an MUA might render that message in some distinctive
   fashion"

It is notable that MUAs and MDAs are mentioned here as devices that would 
and should be involved in MARID authentication system and could potentially
filter the bad messages. While not totally  true in all cases, in majority 
of situations MUA can be said to be located within same organization or
network as location of user mailbox (which is where MDA delivers the message)
as such the previous mail delivery preceeding MUA would be within same 
organozation. Similarly MDA may also not be on network boundary but maybe 
futher steps away from incoming mail server gateway for that organization.
So we are expecting devices not located on the network boundary to perform 
MARID authentication and filtering which directly contradicts previously 
mentioned section (*1*). The same section 2.1 futher (right after *1*) 
states that:
   (*3*)
  "The mechanism of this document also seeks to authenticate the mailbox
   associated with the MOST RECENT introduction of a message into the
   mail delivery system.  In simple cases, this is who the mail is from.
   However, in the case of a third-party mailer, a forwarder or a
   mailing list server, the address being authenticated is that of the
   third party, the forwarder or the mailing list."

It is unclear from the document if in case of MUA or MDA (if it is not 
located on the network boundary) if the "MOST RECENT introduction of a 
message into the mail delivery system" refers to the server immediatly 
proceeding in email path (the mailbox location server in case of MUA or 
gateway mail server in case of MDA) or the outgoing mail server of the
network that proceeded this (which by the text of ietf-marid-core document 
would be the only step in email transmission that protocol should be 
trying to secure).

I'm going to assume that since the ip address of the connection is within
same network we can not be talking about authentication server that is 
outside and several hops away and that MDAs are expected to do MARID 
authentication ONLY IF it sits on network boundary and message is coming
from outside the current network. In such a case, this should be explicitely
stated to avoid any confusion.

However this brings us back to MUA which is receiving the message from
server within same network and which does not participate in SMTP 
transmission at all and clearly can not see ip address of SMTP client
or see parameters of email envelope including new SUBMITER parameter 
described in ietf-marid-submitter draft. 

So MUA is somehow expected to be able to identify PRA that was used in 
"MOST RECENT introduction of a message into the mail delivery system" and 
somehow expected to identify ip address of the smtp client at that time. 
The problems can possibly be resolved by having MUA lookup client ip 
address in the Received header, but to my knowledge Received header has 
not been standartized and there is no requirement for SMTP server to 
insert into it ip address of the client (although many do).
Additionally Received headers are regularly forged and relying on it
might allow for a way to assert certain PRA as correct (as would be
seen by MUAs and thus by end-users) when in fact its not.

Going futher in the document I see another mention about what MUA should do:
  (*4*)
  "When displaying a received message, an MUA SHOULD display the
   purported responsible address as defined by this document whenever
   that address differs from the RFC 2822 From address.  This display
   SHOULD be in addition to the RFC 2822 From address."
  (*5*)
  "When a received message contains multiple headers that might be used
   for the purported responsible address determination, an MUA should
   consider displaying all of them. That is, if a message contains
   several Resent-From's, a Sender and a From, an MUA should consider
   displaying all of them."

First of I immediatly note that PRA is now defined in different draft and 
referenced in first paragraph should be to that draft instead of "this 
document". The PRA draft has very specific rules on how to determine PRA.
Those rules should in theory lead to finding the same PRA that would have 
been used by last SMTP server that checked it. But we don't actually know
if such SMTP server ever did check PRA nor do we know ip address of the 
SMTP client that such SMTP server should have verified by means of 
CallerID algorithm to be able to confirm that message is "safe".

Additionally I note going back to the beginning (see *1*) that purpose
of the SenderID is to authenticate servers within different organization
but the PRA seen by MUA might well be based on the server information 
within same organization if it had several servers on the receiving side
For example if when email was received by gateway server and was forwarded
to another server and only then to MDA, intermediate servers might have 
added their own "Resent-From" header (within same organization network) 
and this would alter PRA as seen by MUA and this new PRA no longer 
represents address of who was responsible for transmitting email to the 
current network which as per *1* is what we should be focusing on.

The above two problems means that PRA displaed to the user in MUA as 
proposed by the draft can not be relied to have been verified, nor can
it be certainly established that it represents an address of the outside 
organization responsible at some point for delivery of email. This means
this PRA displayed to end-user has minimum value (no more so then unverified
"From:" header) and likely would onlyconfuse such end-users (in particular
if recomendation in *5* is followed and many different "Resent-From" and 
"Sender" addresses are all displayed to end-users).

I note that this is a very fundamental issue. The whole purpose of Caller-ID
was to authenticate address as it is seen by end-user in MUA. But if it turns
out that MUA can not be certain that address it is displaying has been
authenticated or not, then what value does invention of this new address 
field has and that of entire algorithm?

---------------------------------

As to the way around the above problems, I remind that original SPF has 
new SPF-Received header which is used so that server doing authentication 
could log ip address of the client it authenticated, what was the email 
address it authenticated as well as results (pass, fail, neutral, etc...). 
Its possible that the way around is to use the same mechanism and require
that MUAs display PRA field only if it can find it in the top-most
"MARID Received" header and only if MUA can be certain that such header
has been added by MTA that is on the same network as MUA itself.

Also large portions of the draft that are dealing with MUAs and MDAs 
doing authentication and filtering should be rewritten. It should be made 
clear that authentication and message rejection based on PRA can only 
reliably be done during SMTP email transmission (authenticating
connecting SMTP client) and not by any device afterwards.

---
William Leibzon, Elan Networks:
 mailto: [email-masked]
Anti-Spam Research Worksite:
 http://www.elan.net/~william/asrg/