ietf-asrg
[Top] [All Lists]

[Asrg] Are we allowed to extend the SMTP protocol?

2004-05-09 16:31:40
People,

I was wandering through the SMTP RFC (http://www.faqs.org/rfcs/rfc2821.html and other places), and I got to section 4.2 which is the reply codes that the receiving MTA sends back to the sending MTA. I think this is where we ought to focus our thinking.


Can we modify the SMTP to add an authenticating capability? I think so. In particular, I notice the following in the RFC:

The list of codes that appears below MUST NOT be construed as
  permanent.  While the addition of new codes should be a rare and
  significant activity, with supplemental information in the textual
  part of the response being preferred, new codes may be added as the
  result of new Standards or Standards-track specifications.
  Consequently, a sender-SMTP MUST be prepared to handle codes not
  specified in this document and MUST do so by interpreting the first
  digit only.


What if we added a code 320 or 453, I think, which means authenticate yourself to me? Then sending MTA will then queue the message for retransmission later.

The receiving MTA would then send a Turing-difficult test to the erstwhile sender of the message, such as a pointer to a graphic that the sending MTA has to read (e.g. http://www.commercialventvac.com/~jeffs/mail.jpg <http://www.commercialventvac.com/%7Ejeffs/mail.jpg>) or it could be all text that a human still has to parse for example

A H H A RRRR DDDD TTTTTTT EEEEEE SSSSS TTTTTTT
 A A        H    H    A A     R   R D   D       T    E         S         T
A   A       H    H   A   A    R   R D    D      T    E          SSSS     T
AAAAAAA      HHHHHH  AAAAAAA   RRRR  D    D      T    EEEE           S    T
A     A      H    H  A     A   R   R D   D       T    E        S    S     T
A     A      H    H  A     A   R   R DDDD        T    EEEEEEE   SSSS      T


Or it could be a sound clip.
The sender of the message takes the test, and puts the answer in the subject field. This message is sent to the receiving MTA. The receiving MTA has to go through the message until it gets to the subject field so that it knows that this is a test and not a message.

Once the sender has passed the test, then the receiver can add the sender to a white list which is under the control of the user. I realize I am not very structured - this idea is somewhat half baked. The user would have three lists of addresses of correspondents: a white list, which can be passed without further testing; a blacklist, which can be rejected without further testing; and a graylist, which must be tested. Whenever a new correspondent appears, they automatically are added to the graylist by the MTA. If the user decides that this correspondent is a spammer, then they can add the user to the blacklist.


There are a couple of problems with this. One is that the Turing difficult test is language dependent. I am used to thinking in terms of a roman alphabet, but what if the receiver and the correspondent are Israeli or Arabic? Another problem is that if the correspondent were to somehow learn that an address was on the receiver's white list, then the correspondent could send a message with that address. The user response in that case would be to move that address from the white list back to the gray list.

The big advantage of this scheme is that it requires modification only to the receiving MTA and requires no changes to the UTAs. My intuition tells me that there are far fewer MTAs than UTAs and since the MTAs are under the control of sysadmins and not users, it will be easier to update them.



So, I couple of questions:

1)  Does this sound like a good idea?

2)  If it is a good idea, then what do we do next?

3) If it is a bad idea, then why is it a bad idea, and can it be fixed or is it hopeless?


I recognize that this is a variant on challenge/response, but I missed most of the discussion of challenge/response and I am not sure I understand why it is not a good idea.

Many thanks,


Jeff