Re: [Asrg] Some data on the validity of MAIL FROM addresses

Michael Rubel <> Tue, 20 May 2003 23:38 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id TAA05916 for <>; Tue, 20 May 2003 19:38:21 -0400 (EDT)
Received: (from mailnull@localhost) by (8.11.6/8.11.6) id h4KN4rZ13522 for; Tue, 20 May 2003 19:04:53 -0400
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id h4KN4rB13519 for <>; Tue, 20 May 2003 19:04:53 -0400
Received: from ietf-mx ( []) by (8.9.1a/8.9.1a) with ESMTP id TAA05904; Tue, 20 May 2003 19:37:50 -0400 (EDT)
Received: from ietf-mx ([]) by ietf-mx with esmtp (Exim 4.12) id 19IGel-0001p8-00; Tue, 20 May 2003 19:36:31 -0400
Received: from ([] by ietf-mx with esmtp (Exim 4.12) id 19IGel-0001p5-00; Tue, 20 May 2003 19:36:31 -0400
Received: from (localhost.localdomain []) by (8.11.6/8.11.6) with ESMTP id h4KN3BB13471; Tue, 20 May 2003 19:03:11 -0400
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id h4KN2IB13430 for <>; Tue, 20 May 2003 19:02:18 -0400
Received: from ietf-mx ( []) by (8.9.1a/8.9.1a) with ESMTP id TAA05857 for <>; Tue, 20 May 2003 19:35:14 -0400 (EDT)
Received: from ietf-mx ([]) by ietf-mx with esmtp (Exim 4.12) id 19IGcG-0001o2-00 for; Tue, 20 May 2003 19:33:56 -0400
Received: from ([]) by ietf-mx with esmtp (Exim 4.12) id 19IGcF-0001nw-00 for; Tue, 20 May 2003 19:33:55 -0400
Received: from localhost (localhost []) by (Postfix) with ESMTP id A29EF5D7; Tue, 20 May 2003 19:34:49 -0400 (EDT)
From: Michael Rubel <>
To: Vernon Schryver <>
Subject: Re: [Asrg] Some data on the validity of MAIL FROM addresses
In-Reply-To: <>
Message-ID: <>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <>, <>
List-Id: Anti-Spam Research Group - IRTF <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
List-Archive: <>
Date: Tue, 20 May 2003 16:34:49 -0700

mr> Here's a better example.  Should mail that contains the string "sex" in the
mr> subject line be Rejected during the smtp session?  Or does it make more
mr> sense to carry that little piece of information through to spamassassin or a
mr> Bayesian filter, where it can be combined with a lot of other information
mr> about the message and recipient to make an intelligent decision?

vs> That suggests the underlying assumption behind saying that SMTP status
vs> codes are obsolete.

That's right, I'm saying that where SMTP status codes leak useful
information about your system or your filters back to the spammer, they are

vs> In fact, SpamAssassin is like every other filter at least in principle.  
vs> SpamAssassin is often run during the SMTP session using a sendmail
vs> milter hook.  If SpamAssassin computes a spamish score for the message,
vs> the message can be rejected.  See

I know it's possible, Vernon, but I don't think that it's a good idea.  I
want to give spammers as little information to work with as possible.  If it
means my messages occasionally end up dumped as false positives, that's a
price I'm willing to pay.

mr> Providing immediate Reject allows the spammer to keep trying until he's
mr> sure the message has gotten through, and it allows him to learn about the
mr> filtering behavior of your system or yourself.  

vs> No, you hide no information by giving it with a DSN instead of an SMTP
vs> status response.  If you don't want to tell the spammer that the
vs> message was detected as spam, then delaying the detection is irrelevant.
vs> You won't be sending either a bounce or a negative SMTP status response.

We don't disagree here.  I have no problem with SMTP responses that do not
leak information.  It's the ones that leak information I have a problem
with.  DSN's only leak information if a spammer gives his true return
address, and can be implemented so as to leak it very slowly.  They may be
a reasonable compromise.

But I think it would be better to not send any notification whatsoever
until the final recipient has made a filtering decision.  I can imagine
situations where a user has a .forward file in a blacklisted or otherwise
normally-filtered domain, and might need to work around domain-based
spamfilters to allow the forwarding to happen.  Or perhaps the user wants
to implement special whitelisting and blacklisting, or has his/her own
Bayesian filter, or wants to operate in "stealth" mode.  User policy may 
be more or less strict than normal system policy.

Can you think of a good reason *not* to hold off on sending a DSN until
the final (user's) filtering decision has been made--for example, when the
message gets dumped in the recipient's "spam" folder?  Apart from the 
system load argument, that is.

mr> If you send a blatently spam-like message to a mail host, do you expect to 
mr> receive a bounce if it is not delivered?

vs> What is a blatently spam-like message and in whose eyes?  If you
vs> send a message that you don't think is blatently spam-like, don't
vs> you expect an indication that it was rejected?

I'd not be surprised if I didn't receive one.  I certainly don't and
shouldn't expect a bounce during the SMTP transaction.

mr> Because "best practice" dictates that all domains would be run by
mr> responsible admins, and that they would run ident. 

vs> I think that's wrong.  I think no BCP says anything good about IDENT.
vs> If I'm wrong, please point out the RFC (whether in the BCP index or
vs> not, other than ) that strongly recommends IDENT.

Fair enough.  I retract the statement, and instead begin it with:  "In an 
ideal world, all domains..."

> > > If we really think that BCP30 is so hopelessly outdated, wouldn't this be a
> > > good place to start rewriting it.
> >
> > I'm not familiar with BCP30...
> I don't want to insult you, but that is definitely the wrong answer here.

Mea culpa.  You're right, I've read rfc-2505 (BCP-30), and should have
done so before responding the first time.  It hasn't changed my opinion 


Asrg mailing list