[Top] [All Lists]

Re: Sender's Declaration of Identity

2005-05-16 14:47:54

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
>     ID
>     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,
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, 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:

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.

      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", 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.

************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *