On Wed, 2004-09-08 at 13:00, Yakov Shafranovich wrote:
Douglas Otis wrote:
This becomes irrelevant should the MTA/Mailbox domain relationships be
viewed as nominal assertions against MAIL FROM and From mailbox domains
and the MTA authentication is an independent operation. Where PRA plays
a role is equally accommodated by the EHLO name anyway.
Hmm. The original intent of all of these before phishing and 2822
headers got thrown in was to verify the parameters of the SMTP
transaction. With the variant scopes we can still do that with ability
to check MAIL FROM via mailfrom scope, and EHLO if CSV is intergrated
into the main record format.
There are a few advantages this seems to miss. By using CSV as a first
step, the format for describing any mailbox-domain relationship with
sending MTAs requires little more than a name list.
Something like:
_spf._mailfrom.my-domain.com. PTR my-isp.com.
_spf._mailfrom.my-domain.com. PTR my-other-isp.com.
_spf._mailfrom.my-domain.com. PTR my-support.com.
-or-
_spf._from.my-domain.com. PTR my-isp.com.
_spf._from.my-domain.com. PTR my-other-isp.com.
_spf._from.my-domain.com. PTR my-support.com.
I had proposed:
_mp._smtp.my-domain.com. PTR my-isp.com.
_mp._smtp.my-domain.com. PTR my-other-isp.com.
_mp._smtp.my-domain.com. PTR my-support.com.
Where an A record flags whether the list is "comprehensive" for either
the MAIL FROM or the From fields. If the associated flag is not set,
then the list becomes nominal information to color mail. PTR should
allow name compression and fit within a single DNS lookup. This would
not require any subsequent lookups to resolve whether
mx001.soup.my-isp.com was a nominal source for my-domain.com as
example.
As for PRA, I think I finally understand your point. The PRA and
SUBMITTER invent a new identity, that of the original agent that
submitted the message, akin to the "Sender" header in 2822. I think what
you are trying to say is that there is no need to resort to those
methods, which are less reliable, when 2821 information is available. Is
that correct?
The EHLO name offers virtually the same information obtained by roving
through RFC2822 headers using the PRA algorithm where the From is being
over-ridden, but the certainty of this EHLO name is suitable for
asserting reputation. Reputation services are not without risk and
being asked to trust the integrity of the mail channel is untenable for
this purpose. Having an authenticated name lowers the cost establishing
a history of use, but neither SPF nor Sender-ID offers a reasonable
level of assurance for the domain identified.
If so, does that mean that this entire set of proposals is not useful
for stopping phishing in any way?
Sender-ID does not stop phishing any better than simply asserting the
nominal source of mail and making the authenticated EHLO name visible.
This two step process would obtain better consumer protections with less
information exchanged by DNS and less risk with respect to compliance.
CSV does not add to the SMTP overhead, nor would a name list require
subsequent lookups. A sequence of lookups could comprise a sizable
burden for the receiving SMTP server needed with the collapsed functions
of Sender-ID and SPF, and simply invoking a timeout is not a suitable
solution.
A nominal mailbox-domain sending MTA list is a lightweight approach that
quickly brings results closer to the goal without breaking SMTP. Don't
underestimate the importance of authenticating a name suitable
reputation assertions or the role EHLO can play in this effort.
-Doug