ietf-smtp
[Top] [All Lists]

Re: Sender's Declaration of Identity

2005-05-17 15:08:51

At 02:27 PM 5/17/2005 -0400, Hector Santos wrote:
----- Original Message -----
From: "David MacQuigg" <david_macquigg(_at_)yahoo(_dot_)com>

> Here is an incoming email with no ID declaration.
>
>       EHLO  mailserver7.bigforwarder.com
>       MAIL FROM:<bob(_at_)sales(_dot_)some-company(_dot_)com>
>
> What do you do next if you want to authenticate this message?

Dave,

That should depend on the server, not the client.  However, if I think where
you going with this (and this is not the say I agree with it),  what you are
looking for the server expose to the client how the client can be
authenticated:

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.

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
    S: 250 Validated! Continue

Example #2:

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

Also, I would personally suggest introduce optional enforcement concepts
that makes the proposal stronger in my view.

Example #3

    C: EHLO  mailserver7.bigforwarder.com
    S: 250-hostdomain.com,  Plesase to meet you.
    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.

To further this idea, throw in a RES (restricted) and AUTO modifiers.


Example #4

    C: EHLO  mailserver7.bigforwarder.com
    S: 250-hostdomain.com,  Please to meet you.
    S: 250-ID SPF1-REQ SPF2 CSV-RES
    S: 250 HELP

This would suggest that SPF2 is optional,  CSV is restricted to certain IP
addresses (or domains) and is required if the client falls in this
classification.  Otherwise SPF1 is required.

Example #5

    C: EHLO  mailserver7.bigforwarder.com
    S: 250-hostdomain.com,  Please to meet you.
    S: 250-ID SPF1-AUTO SPF2 CSV-RES
    S: 250 HELP

This would suggest that SPF2 is optional,  CSV is restricted to certain IP
addresses (or domains) and is required if the client falls in this
classification.  Otherwise SPF1 is automatically applied, ID is not
required:

Example #6

    C: EHLO  mailserver7.bigforwarder.com
    S: 250-hostdomain.com,  Please to meet you.
    S: 250-ID SPF1-AUTO SPF2 CSV-RES
    S: 250 HELP
    C: MAIL FROM: <reverse-path>
    S: 451 Sorry, this DOMAIN failed SPF1

Example #7

    C: EHLO  mailserver7.bigforwarder.com
    S: 250-hostdomain.com,  Please to meet you.
    S: 250-ID SPF1-REQ SPF2 CSV-RES
    S: 250 HELP
    C: MAIL FROM: <reverse-path>
    S: 551 Sorry, Please Provide ID command

Example #8

    C: EHLO  mailserver7.bigforwarder.com
    S: 250-hostdomain.com,  Please to meet you.
    S: 250-ID SPF1-REQ SPF2 CSV-RES
    S: 250 HELP
    C: ID SPF2 pra-domain.com
    S: 250 pass!

Example #9

    C: EHLO  mailserver7.bigforwarder.com
    S: 250-hostdomain.com,  Please to meet you.
    S: 250-ID SPF1-REQ SPF2 CSV-AUTO
    S: 250 HELP
    [CVS checking done]
    S: 551 - Sorry, you are not validated

etc. etc.

So basically, you need to map the behavior of all methods and then come up
with the functional specification on how the SMTP server will behave.

Now, will it work?

Probably not.  For many reason, but the most important one from my stand
point is that it is a big change and if we are considering a big change, we
might as well go all the way with other more stronger methods.

But I do think if you continue with the proposal, you should consider the
modifies REQ, RES and AUTO.

What worries me about "going all the way" and including lots of nice options, is that the history of this project shows that even the most trivial of agreements among the different factions are impossible to negotiate. The ID declaration is about as simple and "non-partisan" as I can make it, and you can see the negative reactions that is generating. Imagine the arguments over which keywords (SPF1, SPF2, SENDERID(C), CSV, REQ, RES, AUTO, ... ) will be designated as IANA approved!! If there is way to get the benefit of these options without adding it all to SMTP, and I believe there is, then we should spend our limited time and energy on just getting a simple, neutral way to declare an ID.

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



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