ietf-smtp
[Top] [All Lists]

Re: Sender's Declaration of Identity

2005-05-17 14:18:39


----- 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






<Prev in Thread] Current Thread [Next in Thread>