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: william(_at_)elan(_dot_)net
Anti-Spam Research Worksite:
http://www.elan.net/~william/asrg/