Options for the ID Command


Changing the title, so we can keep the original thread on track.

Hector, I haven't thought through all the implications of your proposal,but I will support it if:1) It provides an unambiguous Identity that we can pick from the SMTPsession without transferring the DATA.

2) The Identity can be used to locate a DNS record with no "hunting".

2) There are no restrictions on the Identity that will favor one methodover another. i.e. It's just an Identity that we can check, no additionalrequirements like it must be the PRA Identity (The reason SUBMITTER is out.)3) You can ram it past the Nattering Nabobs of Negativism. (oops, I'mshowing my age ! :>)


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


At 05:16 PM 5/17/2005 -0400, Hector Santos wrote:

----- Original Message -----
From: <Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>
Sent: Tuesday, May 17, 2005 4:06 PM
Subject: Re: Sender's Declaration of Identity

On Tue, 17 May 2005 14:27:56 EDT, Hector Santos said:

>>     S: 250-ID SPF1 SPF2 CSV
>>
>> So for this server, it supports SPF1, SPF2 and CSV.

> OK.. That's a nice SMTP-extension friendly way to do it.  You've
> got my attention :)

Whoa!  Do you know what you just did?  You just gave me
encouragement and hope to maybe finish my ESMTP email authentication
proposal.  It is fundamentally based on these "optional
enforcement"  backward compatibility support level concepts.

>>     C: ID SPF1 somedomain.com
>
> You really want to just trim this reply back to 'ID SPF1' and
> have SPF still look up the info based on the usual places -
> otherwise you allow an attacker to claim one thing on the ID line
> and something else in the now-unchecked fields.

Good point. I was thinking as a "submitter" replacement to handle
transition points.  But yes, by default, SPF1 would apply to the
current email and/or optionally client domain depending in the
implementor.

      ID SPF1 [responsible-domain]

I always thought SUBMITTER was vulnerable for the reasons you
pointed out, so the same applies here I believe. The only way I
saw around this is with HOP analysis.

>Possibly modifying the ID command to return a list:
>
>    ID CSV SPF1
>
>to say "This mail should be authenticatable via either CSV or
>SPF1", and allowing the server to '550 5.7.1 No acceptable auth
>proto' at that point would be a better approach - Server lists
>the acceptables, client lists the availables, and server then
>says "Yes, we have something that might authenticate when the
>time comes", or "No, we have no possible way to make this work,
>don't even bother sending the MAIL FROM"....

Ahhh, I see, sorta like a PPP LCP negotiation?  Gosh, I think
you are going to force me to finish me work. :-)

>>     S: 250-ID SPF1-REQ SPF2 CSV-RES
>
> Interesting idea - not sure how that would interact with the
> alternate ID command I listed above.  What should a client do at
> this point if it realizes it has no acceptable authenticator?
> Just bail and send an RSET or QUIT, or other action?

I don't have all the answers of course, and nothing would tickle
me pink to get an honest open discussion on the possibilities.

But how to best handle rejection is important and needs to be
discussed as I see this as the major key in addressing backward
compatibility.  The growth of "greylisting" has made these type of
proposal more possible.

The basic idea behind optional enforcment modifier is to begin
offering an backward compatible changing of the mindset the
industry so desperately needs.   Of course, early implementators
would not be so restricted. They will have atleast one method
that is optional, thus allowing a non-compliant clients to
continue.

So initial default is backward compatibility for the client.  If the sender
is eventually deemed problematic, it might move the domain/IP into a -RES
classification based.

As time moves on, each system from small to corporate can decide
how to apply their client/server security policy.  I suspect this
will take a long time, but atleast the avenue will be there for
new policies to grow and become more acceptable and main stream.

The goal is to gradually and eventually eliminate the non-SMTP
compliancy issues that the spammer industry relies on to a very
large degee.

I don't want to speak much about it, but in my more radical
proposal with optional enforcement ideas,  optional "Hours of
operations" is a small and important part it.

    Hours for vendors (social networks)
    Hours for {SPF1, SPF1, CSV, other] compliant clients
    Hours for the general public

etc, including:

    Hours for compliant CANSPAM SPAMMERS

Again, all optional with backward compatibility in mind, to begin
introducing new enforcment policies that can be introduced over time.

> I'm thinking that having the client reply 'ID SPF2 CSV'
> (basically, enumerate the list of offered methods that it
> recognizes/supports), and then the server can either '250 OK' or
> '550 5.7.1 No way..'.  If the server gives back a 250 then it
> also knows which methods to try or not try at the appropriate
> times.
>
> I see this proposal as best suited for a framework to allow the
> server end to say "your mail must be at least this
> authenticated", and for a client to tell the server "Don't bother
> trying methods X, Y, or Z at all" to minimize the server's
> workload, and possibly for a client to have some form of early
> disconnect if it can verify that there is no way the mail will be
> accepted.

Yes, I agreed with the idea of a stronger client/server negotiated
handshake.

The issue will be how the results and correlate them to local mail
policies because ultimately this will defined the level of support for
backward compatibility.

Dave's proposal is attractive because makes us consider all the
proposals out there so see how they can work in concert.

But no idea will be effective until we begin to honestly look at
the enforcement concepts and tying it to local system/server
policies.  I have hope that it may possibly work if we begin with
a "standard" method of defining optional enforcment ideas
regardless of the security method in place.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com