6. Proposals - Sender Verification (was Re: [Asrg] Simple way to verify

Welcome to the group Dennis!

First of all, please follow the posting guidelines for this list (see 
http://www.irtf.org/asrg/asrg_mailing_list_information.htm). I changed 
the subject.
Second, please take a look at this presentation that outlines different 
approaches for email path verification:
http://www.elan.net/~william/asrg-emailpathverification-presentation.pdf

Third, take a look at the technical considerations and requirements 
documents, specifically in regards to anonymity. Sender verification 
proposals tend to conflict with the idea of anonymity and that must be 
take into account. The documents are available at:
http://www.ietf.org/internet-drafts/draft-crocker-spam-techconsider-02.txt
http://www.infobro.com/anon-FTP/infoSource/IRTF/ASRG/draft-irtf-asrg-requirements-xx-05.txt

Fourth, take a look at the CRI proposal:

http://www.ietf.org/internet-drafts/draft-irtf-asrg-cri-00.txt


Dennis Gearon wrote:
> First of all, I hope this is a good place to send or propose or get 
> comments on this idea.
> Secondly, I welcome not only comments, but pointers to what is already 
> being done in this task.
> Third, also, any comments about the usefulness of identifying the sender 
> would be welcome also.
> <<background>>-------------------------------------------------------
> I have looked at drafts and standards for verifying the user sending and 
> email. I did not see any simple way to do it.
> I looked at:
>    http://www.imc.org/ids.html
>
> and listings on it:
>    http://www.imc.org/draft-ietf-smime-sender-auth
>    http://www.imc.org/draft-church-dns-mail-sender
>    http://www.imc.org/draft-fecyk-dsprotocol
>    Some of the background knowledge, especially DNS related technology, 
> is beyond me.
> and:
>    http://www.imc.org/rfcs.html#hosttohost
>
> but found:
>     no listings on it related to FROM verification.
>
>
>
> <<idea>>--------------------------------------------------------------
> Idea: allow mail servers to verify that:
>    A/ Message is actually from a sender.
>    B/ Body of message is the same as originally sent
>    C/ Relay from identified, authorized users only, and using REAL FROM: 
> address.
>    D/ verify to receiving mail server the inverse, that authorized local 
> client sent mail from server, or that message
>        id, body, subjcect, to, and FROM: address came from a user on 
> FROM: address system, no matter from
>        where sent.
>
> ------------------------------------------------------------------------------------------------------------- 
>
> To send mail from authorized mail domain, mail client does following 
> actions:
>    Send mail as usual.
>
>
> Server responds by:
>    1/ Veriying password and username
>    2/ Creates MESSAGE-ID
>    3/ Selects 32 equidistant locations in the binary concatenation of 
> FROM:, DATE:, SUBJECT:, and body of the email.
>        prevents just appending spam to the end of a message, which could 
> happen if mail is intercepted.
>    4/ Harvests 2 bytes from each location
>    5/ Creates an MD5 hash of ( username + DATE: + SUBJECT + MESSAGE-ID + 
> 64 harvested bytes )
>        adds MD5 hash as header titled
>            UDSMIDEqui32-Message-Hash:
>    6/ Stores MESSAGE-ID (if it doesnt' already) with MD5 hash and username
>    6/ Sends mail as usual
>
>
> Receiving server does:
>    1/ Contacts server in FROM: field.
>    2/ If message contains header of 'From-Verified:', that header is 
> removed.
>    3/ Repeats steps 3 through 5 above.
>    4/ Requests verification of sending server that FROM: user sent 
> message with MESSAGE-ID and MD5 hash calculated.
>        If MD5 hash does not match can refuse reciept,
>        if mail is stored for user, whether verified or not, an 
> additional header
>        is inserted called From-Verified: which has values of:
>            TRUE
>            FALSE
>
>      
> ------------------------------------------------------------------------------------------------------------- 
>
> To send mail from a different server than authorized mail domain, mail 
> client does following actions:
>    Send mail as usual.
>
> Server responds by:
>    1/ Selects 32 equidistant locations in the binary concatenation of 
> FROM:, DATE:, SUBJECT:, and body of the email.
>    2/ Harvests 2 bytes from each location
>    3/ Creates Local Message ID
>    4/ Contacts mail server in FROM: address.
>    5/ Sends via an encrypted path:
>        user_name,
>        password,
>        DATE:,
>        SUBJECT
>        64 harvested bytes
>        Local Message ID
>        and requests verification of user.
>    6/ FROM: mail server validates user_name and password, creates:
>        MESSAGE-ID,
>        MD5 hash of:
>            username
>            DATE:
>            SUBJECT
>            MESSAGE-ID
>            64 harvested bytes
>        then stores
>            MESSAGE-ID
>            MD5 hash
>            username.
>            remote server name
>    7/ FROM: mail server then sends via encrypted path:
>        if username and password were matched:
>            Received Local Message ID,
>            created MESSAGE-ID
>            MD5 hash
>                -----OR-------
>        or if username and password were NOT matched.
>            Received Local Message ID
>            FALSE keyword
>    8/ Remote server assembles message as normal, substituting:
>        received MESSAGE-ID for any MESSAGE-ID it would normally create
>        adds MD5 hash as header titled
>            UDSMID-Equi32-Message-Hash
>    9/ sends mail as usual
>
> Receiving server does:
>    nothing different
>
> ------------------------------------------------------------------------------------------------------------- 
>
> additional notes.
>
> If querying for username password cracking is a concern, remote sending 
> can be authorized per user only once per minute or somethign like that, 
> with maybe a ceiling per day, ceiling since last email download, and 
> messages to user inserted into mail spool to inform them about status of 
> verification requests.
> The MD5 routine only executes over a fairly small data set and so 
> consumes a small amount of CPU time
> The messages between servers are very small, and so the encryption 
> routines don't consume much CPU time, not does it add significantly to 
> the internet traffic load.
> Since the TO: field is NOT included in the hash, CC, BCC, and multple TO 
> emailing is not affected; All messages sent at the same time
> The logs for the server would be a little bigger, and would be better 
> kept in a Database for each current month and one day off the tail 
> flushed to a flat file daily.
> Empty bodies are not a problem because the following headers
>    FROM::
>    SUBJECT:
>    DATE:
>
> These fields are 52 characters long WITHOUT EVEN ADDING address to 
> FROM:, and if encoding header is added, the 64 bytes are
> already exceeded without address. If necessary, message can be padded 
> with /x00 bytes.
>
> _______________________________________________
> Asrg mailing list
> Asrg(_at_)ietf(_dot_)org
> https://www1.ietf.org/mailman/listinfo/asrg

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg