[Top] [All Lists]

Re: "Subject" in the envelope (was: Re: Comments requested on draft-malamud-no-soliciting-04.txt)

2004-01-26 21:12:15

--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 :-)