--On Monday, 26 January, 2004 21:10 -0500 Hector Santos
<winserver(_dot_)support(_at_)winserver(_dot_)com> wrote:
Thanks for the feedback John.
I agree 100% with each of your points, most notably having a
"SUBJ" precede the other commands to pre-empt further
unnecessary overhead. About internationalization.
Admittingly, I have to study this more. We are getting hit
hard from some international customers about this in our Web
Mail client and just got a reminder the other day.
You might find it interesting to lurk on the "ietf-imaa(_at_)imc(_dot_)org"
list for a while. Also you might find it worthwhile to read
some of the introductory and analysis material in
draft-klensin-emailaddr-i18n-02.txt (should be posted tomorrow
or Wednesday -- I'm proofreading now and it is considerably
different from -01). There is an attempt at a comprehensive
analysis of the problem and tradeoffs before the proposal --and
the analysis may be the more important of the two.
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 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).
The only comment I have is that we might lost tracing and
auditing if it precedes the commands. If implemented, an
system admin may wish to log the rejected transactions by
atleast FROM and SUBJ, and quite maybe RCPT.
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:
* Rejecting on a subject line is technically trivial,
since it would be lexical and would not require going
out to the network to look things up.
* MAIL must still precede RCPT, since many folks decide
on how to respond to RCPT based on the supposed sender,
and may respond differently to different RCPT commands.
* Any analysis of trace information, history-path
checking, etc., want to be done, if feasible, before
DATA is accepted. Those analysis are often, relatively
speaking, costly, but may still be cheaper than
accepting message content.
But, for logging purposes, one could sensibly make the decision
at SUBJ but accept the MAIL and RCPT commands, not bothering to
perform any validation, or any non-lexical validation, on the
latter two if you had already decided to reject the message.
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 could
lead to some rather strange patterns of error replies, depending
on the sequence of RCPT commands, but it might well be worth it.
Out of curiosity, how do you handle the following problem:
Assume that mail is sent to someuser(_at_)host1 with a reverse-path
of maybebogus(_at_)odd-domain, and that the relevant DNS records are
host1 IN MX 10 host2
IN MX 20 host3
host2 is configured for CBV checking; host3, for whatever
reason, is not. The message reaches host3 (it is a bit bigger,
more responsive, and better connected -- for purposes of
simplicity, assume there are no firewalls or other middleboxes
involved). Host3 tries to pass it along to host2. When host2
attempts CBV validation, it gets a DNS timeout on the host1
domain -- note a timeout, not an authoritative "no" answer.
Since it is configured to not accept messages unless it can do
the validation, it returns a 4yz code to host3, resulting in
host3 requeuing and retrying the message, perhaps for a long
time. Host3 considers that behavior mildly antisocial, since
this is not its problem.
Your thoughts?
Incidentally, this delayed MAIL FROM validation concept is
suggested in '2821'. The same can written about SUBJ.
Yes, I know. I wrote it :-)
best,
john