Subject: Re: Last Call: Anti-Spam Requirements on an SMTP MTA to BCP

From: Gunnar Lindberg <[email-masked]>
Date: Tue, 3 Mar 1998 15:43:27 +0100 (MET)

Ned,

First of all I assume I will get a copy from the IESG with your
comments so that they can be included. I saw no "Cc:" (or was the
suggestion to move the document to /dev/null and go home?).

It's quite true that "MAIL From: <>" is not explicitly mentioned in
the document and I agree that it should (and maybe not only in the
context of sanity checks of "MAIL From:" - some implementations
actually seem to do Relay Authorization based on "MAIL From:", which
I personally think is worse and which can give "interesting results"
when faced with "MAIL From: <>").
    
Weak DNS connectivity can be a problem, but is less of a problem than
one may think. What seems to happen is that the Name Server pointed
out by my resolver sends out the query and even if my MTA gives up
and exits before it gets an answer, the information is cached when
it eventually arrives, so that it's there at the next attempt. OK,
there are still DNS domains with 5 min cache life time *and* weak
connectivity... Can't always win. Sigh.

The suggestion in the draft is to return 4xx at most occasions. Not
everybody agrees to this, but when it comes to DNS based checks I
still argue that's a good thing. Of course DNS TempFail MUST result
in a 4xx response code, but doing so even for an Authoritative NamE
actually gets away with many DNS sync problems etc.

Then, I must say that the message "That battle is over", as someone
put it, is really appropriate.

    o	Many people do "sanity checks" on "MAIL From:" domain and
	they seem to avoid "First Generation Spam"; a good thing.

    o	But, spam evolves too:

	    Return-Path: <>
	    Received: from ...
		  by chalmers.se (8.8.8/8.8.8) with SMTP id MAA14599;
		  Mon, 16 Feb 1998 12:02:18 +0100 (MET)
	    Date: Mon, 16 Feb 1998 12:02:18 +0100 (MET)
	    Message-Id: <[email-masked]>
	    From: 
	    To: 
	    Subject:  Turn Your Computer Into a Personal Mail Server

	This is from/about the "Rapid Fire Mail Server (RFMS)", which
	people seem to sell for $200. Second/Third Generation spam.

In fact, it may take a faster keyboard user then I am to keep the
document up to speed with spam evolution.

	    Gunnar

---

From: Ned Freed <[email-masked]>
Date: Tue, 03 Mar 1998 09:13:33 -0800 (PST)

> suggestion to move the document to /dev/null and go home?).

I do not want to see this document abandoned. I think it is an excellent
starting point for something good. My only objection is over the document
moving forward in its present form.

My suggestion was that the document not be accepted until it has received
comprehensive and thorough review by a significant number of experts on email
in general and SMTP in particular. I turned up several problems that I believe
need to be addressed besides the MAIL FROM:<> issue; I have no reason to
believe that additional review done by persons other than myself won't turn up
other problems as well.

I don't think a WG is needed to do this, but that's just my take on it; it is
the IESG that will decide. Nevertheless, I believe additional review is
required before it is appropriate for this to become a BCP.

> when faced with "MAIL From: <>").
    
Indeed, relay checks based on MAIL FROM is yet another problem area that needs
to be mentioned.

> connectivity... Can't always win. Sigh.

Whether or not this is a problem isn't relevant to my objection; the point I'm
trying to make is that the discussion of various issues is inadequate. I've
said it before and I'll say it again: I completely agree that tardy DNS
behavior is rarely a problem in practice with these sorts of checks when the
checks are properly implemented. Pathological cases can develop where the retry
rate for the message interacts with DNS cache time outs in exactly such a way
as to guarantee that a message is never delivered, but this is far more likely
to be associated with client DNS queries rather than server DNS queries.

> actually gets away with many DNS sync problems etc.

Yes, but nowhere in your document do you actually say this. What you do say is:

   The MTA SHOULD be able to perform a simple "sanity check" of the
   "MAIL From" domain and refuse to receive mail if that domain is
   nonexistent. To overcome temporary errors/problems in the DNS, 4xx
   Return Codes are strongly recommended; however the MTA MAY allow for
   Return Codes that show real DNS state - 4xx for temporary problems
   and 5xx for NonExistent domain.

And elsewhere you say:

   However, 4xx Temporary Errors may have unexpected interaction with
   MX-records. If the receiving domain has several MX records and the
   lowest preference MX-host refuses to receive mail from a certain
   "MAIL From" domain with a "451" Response Code, the sending host may
   choose to - and often will - use the next host on the MX list.

And:

   10) MUST be able to configure for different Return Codes for
       different rules (e.g. 451 Temp Fail vs 551 Fatal Error).

Now, being the knowledgable person that I am, I know what you're trying to say
is that temporary failures MUST return a 4xx and permanent failures SHOULD
return a 4xx but MAY return a 5xx.

But it is also possible to read this as saying that an MTA should return 4xx on
temporary failures but MUST allow itself to be configured to return 5xx, and
moreover cases arise where such configuration is the right thing to do. And I
have way too many years of experience with standards work not to think that
this is EXACTLY how some people will read it, and will implement it, and all
sorts of operational problems will result.
 
> document up to speed with spam evolution.

This is actually the one usability issue I don't especially care if the
document addresses. Sure, it is true that none of the measures this document
describes stand much chance of being effective in the long term -- in fact, the
documenting of them and widespread adoption of them will inevitably lead to
them becoming less effective.

But this is the way of all standards and most especially BCPs -- the problem
they seek to solve either vanishes, mutates, or a better solution comes along.
We don't think its necessary to put disclaimers as to the inevitability of
obsolescence in other standards documents so I see no reason to require
discussion of it here either. The BCP label is enough of an indicator that this
is transient stuff likely to require updating on a regular basis.

In conclusion, I do believe that the value of having such a document will more
than offset the harm that will inevitably come from people misreading it and
using the facilities it provides improperly. But this in no way diminishes our
responsibility to attempt to minimize the chances of this happening by being
thorough and complete.

				Ned