William,
Thanks again. I am reviewing the presentation you presented, and although I am
not finished I think I detect a different approach to analyzing 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