At 10:55 PM 5/15/2005 -0400, Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu wrote:
On Sun, 15 May 2005 18:23:55 PDT, David MacQuigg said:
> The proposal is to add an ID command to the SMTP exchange, after EHLO, but
> before MAIL. My main concern is backward compatibility. Here are the
> relevant paragraphs:
>
> EHLO mailserver7.my-company.com
> ID mycompany.com
> MAIL FROM: bob(_at_)sales(_dot_)my-company(_dot_)com
You get the point:
Unfortunately, there is no agreement on how this should be done.
Some believe firmly that it should be done in the EHLO command at the
start of each session, others insist that it should be done in the
MAIL command with each email. Still others think the true Identity
should be extracted from one or another of the email headers that the
recipient actually sees. Adding to the confusion is the fact that
each of these identities may legitimately differ from the Identity
that is to be authenticated, and may differ in having extra
"subdomain" labels that are not easily separated from the Identity to
be checked.
and then promptly decide to ignore it. The reason that there is disagreement
is because the different choices have different semantics. In addition,
many of
the schemes involve the inability of the sender to overload a field. So for
instance, if you're trying to send a phish using a MAIL FROM: of @ebay.com,
you're *stuck* with that MAIL FROM.
The different semantics are irrelevant to the initial declaration. The
common semantic is "This is the ID to be checked." Once you have that ID,
then you can do a query to a single location, and find out what
authentication methods the ID owner offers. The "overloading" you refer to
is not necessary if the declared ID has its own field.
The ID is used only to locate the authentication records. The actual check
is done per the requirements of whatever method is specified in the DNS
records at the ID. For example, if the ID is ebay.com, and ebay says "Here
is an SPF record to use in checking that IP", then the check will be done
against the MAIL FROM and HELO domains. If ebay says "Here is a Sender ID
record", then it will be a different set of domains that gets
checked. Whatever method is used, it is the ID that is responsible to
chose the method and provide proper DNS records for that method.
Your proposal would allow:
EHLO mailserver-7.my-company.com
ID some-spammer-controlled-domain-that-will-verify.com
MAIL FROM:<moby-phisher(_at_)ebay(_dot_)com>
In addition, being able to pick-n-choose and feed the value from a MAIL FROM
to a scheme that wants to verify EHLO or the PTR of the source just opens up
a lot of attacks.
The reputation check on some-spammer... will stop this example. All
methods depend on the reputation of the ID, whether that ID is assumed or
declared.
So how exactly does this improve the situation?
See section 2 of the draft for a summary of the advantages. I've
re-written this, hoping to make it more clear. Here are the re-written
paragraphs:
"""
One way to standardize the Identity declaration is to use a new
field, independent of existing fields, and not constrained by any
pre-existing semantics.
EHLO mailserver7.bigforwarder.com
ID bigforwarder.com
MAIL FROM:<bob(_at_)sales(_dot_)some-company(_dot_)com>
One advantage of this syntax is that the sender's ID is explicitly
declared, not just assumed from existing information. Not only will
this remove the current uncertainty as to which ID the sender intends
to use, but false information here is evidence of a serious problem,
not just a forgivable error in passing on existing information (a
long-standing problem with email). This will greatly reduce the
administrative burden in deciding whether to trust a sender.
Another advantage is that there is no "hunting" for DNS records at
various locations and multiple levels of a deep subdomain tree. The
ID should provide the exact location where the authorization records
will be found.
"""
I don't know how to say it any better. Perhaps an example to illustrate
the first advantage would help. If you get an email that says MAIL
FROM:<someone(_at_)ebay(_dot_)com>, but ebay says NO, it may be impossible to trace
the source of the forgery. The sending MTA is just passing on information
that it received, and the "chain-of-trust" gets fuzzy very quickly. If the
sending MTA declares "ID ebay.com", then it cannot deny responsibility for
its unauthorized use of that name.
I'm not sure if this is any more clear, but please let me know if there is
still confusion.
--
Dave
************************************************************ *
* David MacQuigg, PhD email: david_macquigg at yahoo.com * *
* IC Design Engineer phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. Tucson, Arizona 85710 *
************************************************************ *