From: rja@corp.home.net (Ran Atkinson)
Message-Id: <970325121934.ZM2119@borg.eos.home.net>
Date: Tue, 25 Mar 1997 12:19:34 -0800
In-Reply-To: Philip Hazel <ph10@cus.cam.ac.uk>
        "Re: Null reverse path on non-error messages" (Mar 25, 14:43)
References: <Pine.SOL.3.96.970325143030.26729H-100000@taurus.cus.cam.ac.uk>
To: drums@cs.utk.edu
Subject: Re: Null reverse path on non-error messages
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

On Mar 25 14:43, Philip Hazel wrote:

% We have found it very helpful in reducing the level of spam to check
% that the address given in MAIL FROM at least refers to an existing
% domain. (This used also to catch students who perenially try to mail
% from "god@heaven.com", until some bozo registered heaven.com.
% Quite why  heaven is always seen as a commercial enterprise,
% I don't know.)

  I have (not quite correctly running) code in my _personal_ MMDF source
tree that applies such checks and puts the messages into a "bad
message queue" for subsequent manual processing on the same
grounds.  I know of a number of other operational sites (using
different MTA software :-) that do the same thing.

% Now the spammers are learning to use <> as the sender address, which
% makes checking at MAIL FROM time impossible. All one can do is
% subsequently do checks on From: etc., and by then it is too late to
% reject the message other than by sending 5xx after the "." line, and by
% experience that does not stop certain MTAs from attempting to send the
% message again.

  In some sense, black-holing SPAM without any error indication
is productive for non-SPAM sites -- in that it doesn't give the spammer
any clue that their input is being dropped rather than delivered
so the spammer won't resend and clog things up further.

% I still look at each message with a sender of <> that cannot be
% delivered from this system. ... However, the number of such
% messages that are the result of spamming and other abusive activities
is
% rising, and the time will come when I just configure my MTA to ditch
% them. This will be a pity, IMO.

  While I don't object to permitting a sender of <>, it might be useful
to note in the document that "An MTA MAY drop messages with a sender
of <> if that is required by policy local to that MTA."

  Such a statement would explicitly permit sites like mine (or in future
possibly running my MMDF port/enhancement) to continue the current
operational practice without becoming standards-violating ex post facto.

I'll happily go along with whatever others think is best.

Ran
rja@home.net

PS:  As an aside, much of the SPAM I've seen was originated from a
  PC and sent via SMTP (outbound-only) to the same box that hosted
  its POP3 service.  It might be useful to encourage first-hop MTAs
  to perform sanity-checking on the source-addresses PRIOR to
  transmitting to the wider world.  This would not be enforceable,
  but it would not hurt to encourage folks to operate their
  dual POP3/SMTP boxes in a sanity-checking mode. :-)

[DISCLAIMER:  I don't have anything to do with the Mail services
		operated by my employer and they aren't using my
		MTA software.  I also don't speak for my employer.]