Re: Sender's Declaration of Identity

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

The more propery way to do this today with ESMTP would be for the server to
expose what methods it support:

    C: EHLO  mailserver7.bigforwarder.com
    S: 250-hostdomain.com,  Plesase to meet you.
    S: 250-SIZE 5120000
    S: 250-ETRN
    S: 250-ID SPF1 SPF2 CSV
    S: 250-AUTH CRAM-MD5 LOGIN PLAIN PLAIN-MD5 SHA-1
    S: 250-AUTH=LOGIN
    S: 250 HELP

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

The compliant client can choose one.

Example #1

    C: EHLO  mailserver7.bigforwarder.com
    S: 250-hostdomain.com,  Plesase to meet you.
    S: 250-SIZE 5120000
    S: 250-ETRN
    S: 250-ID SPF1 SPF2 CSV
    S: 250-AUTH CRAM-MD5 LOGIN PLAIN PLAIN-MD5 SHA-1
    S: 250-AUTH=LOGIN
    S: 250 HELP
    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.

It would also address this issue:

   C: ID CSV somedomain.com
   S: 551Sorry, not validated.  Do not continue.

But might be conflictive with the state flow with our CSV is done, Dave can
answer that.


because CSV checking would still happen at the regular time.

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

    S: 250-ID SPF1-REQ SPF2 CSV
    S: 250 HELP

Which would suggest that SPF1 is required if the optional SPF2 or CSV is not
used by the client.

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

pgpitUe2csGnO.pgp
Description: PGP signature