I'm not advocating either #1 or #2 from your list below in either the
presentation or notes - both are just the basic or summary of some
non-crypto source-authentication approaches but not speciying exact details.
As far as my proposal it'd be a lot more complex and mail tracking with
dns would be just one component of it (one of about 8 drafts) and I'n not
advocating use of either envelope "MAIL FROM" or header "From", I'd rather
actually create new header for authenticated sender and only when this new
header is absent then heder "From:" can be used. But envelope "MAIL FROM"
is changeble for in-between mail servers (maillists, forwarders) and hence
it should be used on per-transaction authentication (where as header "From"
be be used in authentication the source). When I find time to write all these
drafts, I guess you will see what I mean - right now I'v presented bits
and pieces and it may seem like there are scope issues, overall I
think this is eliminated (I guess by introducing more complexity...).
And I (and I'm sure other members of reseach group too) would more then
welcome differentanalysis approaches. In fact at some point we will need
to come with list of what and how needs to be analyzed and then have it
done for each proposal and having different parallel analysis done would
be quite usefull. So it maybe good idea to write out more specs on how you
would analyze a proposasl, though having requirement is often necessary in
order to do it.
William,
Thanks again. I am reviewing the presentation you presented, and
although I am not finished I think I detect a different approach to
nalyzing proposals (though not fatal, and as I said I am not finished a
complete review) in your presentation. For example the analysis of the
'IP of mail sender' drafts.
From what I understand of the methodology it would not be limited to
MAIL FROM: (recognize I am talking about the method not protocol
conformance). The goal is to authenticate the authorization to act as
an originating MTA for a domain, however I see at least two methods for
testing the validity of that method.
1) Receiving MTA performs a DNS query on the connecting/originating IP
for the appropriate resource record to determine authorization for SMTP
origination for the domain involved (the domain is determined by either
MAIL FROM: OR From:,
or;
2) Receiving MTA performs a DNS query on the connecting/originating IP
for the appropriate resource record to determine authorization for SMTP
origination for the domain involved (the domain is determined by either
MAIL FROM: AND From:.
These are fundamentally different in effect though they use the same
methodology. In your example you analyzed the approach #1 only.
Respectfully, my reading (and not yours) does not use the same approach
for any of the proposals yet I am satisfied that your approach is valid
and bears out the results you concluded.
Using my approach (step 1) I first strip the proposal, unless it is of a
protocol implementation, of all of the transport baggage, in this case
SMTP/ESMTP enveloping failures and RFC822 header forge-ability. Then
( step 2) abstract the proposal to it's essence (core functionality), in
this case 'authentication of authorization as an SMTP originator'. The
next step (step 3) analyzes the scope of the proposed solution, in this
case RR via DNS.
At that step I have determined a hurdle for this proposal, on
origination SMTP MUAs (as we see them) should always be allowed by a
local server. But I don't discern a mechanism to establish that
relationship, not a fatal flaw, but one that can introduce a loophole
or worse overhead in the core of the scope (DNS). If in fact every
client connection must be verified (Con). I also notice that the
proposed method does not require a lot of transactions to make the
fundamental determination e.g. can this IP send messages into the MTS
(Pro). Conclusion the proposal has scoping issues.
This represents a higher level analysis of the methodology (authentication
of authorization) as opposed to your deeper analysis of each of the
proposals vulnerabilities to subversion. Usually scoping issues such
as this can be fixed by either simplification or complexity, the
decision is up to the author I guess. The current requirement is that
the proposal be easy to use, but it does not have to be simple.
I think in general that this type of approach may be promising on that basis.
I would appear that a plausible implementation of this component (which
is not a full solution I think) would only verify whether the connecting
MTA was authorized as an SMTP originator, and nothing else (simplification).
Other issues such as DNS vulnerabilities are not pertinent to that
analysis (though it could be an impact on an implementation that did not
consider those risks).
I know you did a lot more than a cursory analysis and it is well done,
it just occurred to me that there are different ways these proposals
may be analyzed. Hopefully, an alternative method (for this 'researchy'
group) of evaluation will allow a little more thoughtful scrutiny of
the proposals moving forward and a little latitude for the author to
alter the proposals method or premise to derive a better result.
my $.02
-e
On Wednesday, April 02, 2003 12:05 PM, william(_at_)elan(_dot_)net
[SMTP:william(_at_)elan(_dot_)net]
wrote:
I'm reforwarding my email verification notes. For some reason they do not
appear in the archive for my original post (anybody know why this happens?
https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg01246.html)
The notes were also used in the presentation at:
http://www.elan.net/~william/asrg-emailpathverification-presentation.pdf
To a degree I need this post, so it goes to archive (so I could reference
it in the summary I'm working on).
---------- Forwarded message ----------
Date: Wed, 12 Mar 2003 01:59:32 -0800 (PST)
From: william(_at_)elan(_dot_)net
To: ASRG <asrg(_at_)ietf(_dot_)org>
Subject: Email Address Verification Notes
8<...snipped to save bandwidth...>8
----
William Leibzon
Elan Communications Inc
william(_at_)elan(_dot_)net
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg