----- Original Message -----
From: "John C Klensin" <john-ietf(_at_)jck(_dot_)com>
To: "Hector Santos" <winserver(_dot_)support(_at_)winserver(_dot_)com>
Cc: <ietf-smtp(_at_)imc(_dot_)org>
Sent: Monday, January 26, 2004 11:12 PM
Subject: Re: "Subject" in the envelope (was: Re: Comments requested on
draft-malamud-no-soliciting-04.txt)
Incidentally, this delayed MAIL FROM validation concept is
suggested in '2821'. The same can written about SUBJ.
Yes, I know. I wrote it :-)
Yes, I know. :-)
You might find it interesting to lurk on the "ietf-imaa(_at_)imc(_dot_)org"
list for a while.
I just subscribed. I'm catching up with the archive.
From my perspective, the internationalization issues are more
important, long-term, than the spam ones. Internationalization
will be with us forever, or at least as long as people use
different languages and scripts. I think that by, say, a decade
from now, we either will have the spam situation under control
or it will have killed email as we know it --regardless of
protocols-- as a useful tool.
I see your point. I don't have much to say about internationalization at
the moment, but I intend to put more time into it.
I am not the only person who has
reached that conclusion although I have no idea whether we
constitute any sort of majority or consensus. You may disagree,
but that conclusion is the main reason why changes that are
helpful to both spam-fighting and internationalization tend to
get more support than one that attacks only one of them
(especially only spam).
I don't disagree with you if you feel internationalization is important. My
only basic feeling is that I have a fundamental (and also long standing
ethical) design approach that a data transport system is just that - a
transport system and it has no business in the "data interpretation" game,
especially for passthru system. With the exception of network control
lines, the only thing I feel SMTP should be dealing with is client/server
access control concepts in order to established an authorized or acceptable
transaction. The AVS (AntiVirus/Spam) problem has highlighted this very
clearly. So although I would think it is two separate issues, I don't
disagree that both should be part of a new solution. I trust your judgment
on the internationalization issues.
You brought up the excellent point about the SUBJ line idea and
international string characters. That has to be considered in the design
for this idea, if it is implemented.
I've often found it helpful to separate the question of "what
information do we to need to make decisions" from "what do we
want to log". I clearly haven't worked through a complete
analysis, but, for this situation and your proposal, my quick
reaction is that I'd want to have SUBJ/ MAIL/ RCPT / Trace /
DATA because:
Right. I agree. I don't think having this particular order will effect
specific implementation designs by vendors to offer auditing/tracing and or
different delay validation logics.
We learned from our CBV work that it works best to delay the
MAIL FROM validation until the RCPT is provided. If RCPT is
going to refused, there is no need to perform the CBV. This
was an overwhelming major improvement since atleast 60-70%
recipients attempts on our site are rejected. In any case, I
agree. SUBJ should probably precede the other commands and
implementations can chose when to validate it.
You presumably then do the CBV on the first otherwise-successful
RCPT command and not before or after that, correct?
That is correct John. It is only done once when the first "RCPT TO:" is
determined to be acceptable address that would allow the session to
continue. When CBV is called and it is returns a rejection response to
SMTP, then SMTP will reset the state machine and force the client back to
MAIL FROM. If CBV returns a positive response, it is no longer called if
there are additional RCPT commands.
That could lead to some rather strange patterns of error replies,
depending on the sequence of RCPT commands, but it might well be worth it.
Good observation. What I have found is that the end result is the same
whether sessions are done with multiple RCPT or individually (when true
rejections is detected). Nothing we can do about a CBV passing the test. I
could go into detail with real SMTP log examples illustrating this if you
like to see this.
The only specific design implementation point I can make is that if a CBV
rejection occurs when called at RCPT, the SMTP server resets the state
machine forcing the client back to the MAIL FROM state. This has helped
stop spammers from continuing to issue new RCPT commands. This helped to
also reduce any RCPT user validation overhead.
Off the top of my head, without rechecking, I seem to recall a thought
process where this might be violating the specification. Can you verify
this for me?
Forget about CBV. What if a client was issuing multiple RCPT commands and
for whatever reason, a rejection threshold was reached? What can the SMTP
server do at this point?
Thanks
PS: I am going to go ahead and write a draft for SUBJ.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com