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

"Tom Thomson" <> Wed, 21 May 2003 17:26 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id NAA29095 for <>; Wed, 21 May 2003 13:26:19 -0400 (EDT)
Received: (from mailnull@localhost) by (8.11.6/8.11.6) id h4LGrDt31110 for; Wed, 21 May 2003 12:53:13 -0400
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id h4LGrDB31107 for <>; Wed, 21 May 2003 12:53:13 -0400
Received: from ietf-mx ( []) by (8.9.1a/8.9.1a) with ESMTP id NAA29072; Wed, 21 May 2003 13:25:48 -0400 (EDT)
Received: from ietf-mx ([]) by ietf-mx with esmtp (Exim 4.12) id 19IXKH-0000qM-00; Wed, 21 May 2003 13:24:29 -0400
Received: from ([] by ietf-mx with esmtp (Exim 4.12) id 19IXKG-0000qJ-00; Wed, 21 May 2003 13:24:28 -0400
Received: from (localhost.localdomain []) by (8.11.6/8.11.6) with ESMTP id h4LGj6B05246; Wed, 21 May 2003 12:45:06 -0400
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id h4LGfqB05081 for <>; Wed, 21 May 2003 12:41:52 -0400
Received: from ietf-mx ( []) by (8.9.1a/8.9.1a) with ESMTP id NAA28644 for <>; Wed, 21 May 2003 13:14:28 -0400 (EDT)
Received: from ietf-mx ([]) by ietf-mx with esmtp (Exim 4.12) id 19IX9I-0000i2-00 for; Wed, 21 May 2003 13:13:08 -0400
Received: from ([] by ietf-mx with esmtp (Exim 4.12) id 19IX9H-0000hz-00 for; Wed, 21 May 2003 13:13:07 -0400
Received: from tthompson ([] unverified) by with Microsoft SMTPSVC(5.0.2195.5329); Wed, 21 May 2003 18:20:24 +0100
From: Tom Thomson <>
Subject: RE: [Asrg] Some data on the validity of MAIL FROM addresses
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
In-Reply-To: <>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-OriginalArrivalTime: 21 May 2003 17:20:24.0813 (UTC) FILETIME=[4416C9D0:01C31FBD]
Content-Transfer-Encoding: 7bit
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: Wed, 21 May 2003 18:14:28 +0100
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

> An IETF/IRTF working group mailing list is not like netnews or SPAM-L.
> It is not merely a forum for stating positions and exchanging views.
> It is a tool for generating and guaging consensus on technical issues.
> Regardless of heat, this mailing list must address the issue of whether
> filtering SHOULD (in the special meaning of RFC 2119) be done during
> the SMTP transaction.  If we can't reach consensus on such a fundamental
> and simple issue, then this mailing list is distinctly worse than useless.

That's true. Since filtering in some form is probably going to be some part
of any realistic solution we ought to be able to get a handle on how things
behave when a filter intervenes.

I don't think there's a simple answer.  I would like to base the answer
around the idea that some types of filtering can appropriately be treated as
being the same as the end-user discarding the mail from his inbox, while
others are more like the MTA being unable to deliver. But there's also the
question of not sending bounces to forged Mail_From addresses. Here are some

We can consider 4 main cases.

1) the filter simply diverts mail into the users junk mail folder, or in
some wasy annotates it so that the MUA will show it as probable spam.  In
this case the MTA must not bounce and must not reject in the SMTP
transaction, since the mail is being delivered correctly.

2) the filter discards mail based on content (including content headers) and
not solely on the envelope. There are a couple of subcases here:
(a) the end-user (envelope recipient) has expressed a desire not to receive
this mail: in this case I can't see that it's any different (so far as the
sender is concerned) from the end user noticing it in his inbox and deleting
it.  The MTA should not reject during the SMTP transaction and should not
generate a bounce.
(b) this is nothing to do with the end user, it's MTA policy - so the mail
was undeliverable by this MTAs rules. Here I think the MTA should generate a
bounce but may reject the mail in the SMTP transaction if the sender is
pipelining - sending the data before knowing whether there is an error.

3) the filter discards mail based on the smtp envelope only. Since the end
user doesn't see the envelope, only the content, there's no way an end user
could base a decision to delete mail from his inbox based on the envelope -
the mail is undeliverable, and the MTA must say so. This should be done
using an error response within the smtp transaction. If the sender is
pipelining and has closed the connection before an error can be raised, a
bounce may be generated.

4) This consideration overrides 2 and 3 above: Because we don't live in an
ideal world, bounce messages may be bad news.  An MTA which can detect
envelope forgery (using RMX or Cryptographic Authentication or HELO domain
non-existence forward Received-From: chain verification or whatever other
future or existing it may have) and discards a message which it knows to be
forged MUST NOT generate a bounce.


Asrg mailing list