ietf-asrg
[Top] [All Lists]

[Asrg] Simple way to verify sender, track mail abusers

2003-09-25 16:24:28
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