Re: [Asrg] 1a. Inventory of Problems - Spoofed mail addresses

david <whatever@davidnicol.com> Fri, 06 February 2004 22:17 UTC

Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25747 for <asrg-archive@odin.ietf.org>; Fri, 6 Feb 2004 17:17:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApEHW-0004iU-NC for asrg-archive@odin.ietf.org; Fri, 06 Feb 2004 17:17:03 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16MH2YN018124 for asrg-archive@odin.ietf.org; Fri, 6 Feb 2004 17:17:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApEHW-0004iE-JI for asrg-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 17:17:02 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25724 for <asrg-web-archive@ietf.org>; Fri, 6 Feb 2004 17:16:58 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApEHU-00078c-00 for asrg-web-archive@ietf.org; Fri, 06 Feb 2004 17:17:00 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApEGW-00073j-00 for asrg-web-archive@ietf.org; Fri, 06 Feb 2004 17:16:01 -0500
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApEFe-0006xh-00 for asrg-web-archive@ietf.org; Fri, 06 Feb 2004 17:15:06 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApEFc-0004OR-3x; Fri, 06 Feb 2004 17:15:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApEEx-0004KH-Cv for asrg@optimus.ietf.org; Fri, 06 Feb 2004 17:14:24 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25349 for <asrg@ietf.org>; Fri, 6 Feb 2004 17:14:19 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApEEv-0006pp-00 for asrg@ietf.org; Fri, 06 Feb 2004 17:14:21 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApEDg-0006cK-00 for asrg@ietf.org; Fri, 06 Feb 2004 17:13:05 -0500
Received: from tipjar.com ([128.121.115.38]) by ietf-mx with esmtp (Exim 4.12) id 1ApECs-0006XC-00 for asrg@ietf.org; Fri, 06 Feb 2004 17:12:14 -0500
Received: from davidnicol.com (adsl-66-143-48-169.dsl.ksc2mo.swbell.net [66.143.48.169]) by tipjar.com id i16MBtNR067824; Fri, 6 Feb 2004 15:12:00 -0700 (MST)
X-Received-From: whatever@davidnicol.com
X-Received-For: asrg@ietf.org
Message-ID: <4024035E.3020100@davidnicol.com>
From: david <whatever@davidnicol.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Brett Watson <famous-asrg@nutters.org>
CC: asrg@ietf.org
Subject: Re: [Asrg] 1a. Inventory of Problems - Spoofed mail addresses
References: <200402061421.29541.famous-asrg@nutters.org>
In-Reply-To: <200402061421.29541.famous-asrg@nutters.org>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: asrg-admin@ietf.org
Errors-To: asrg-admin@ietf.org
X-BeenThere: asrg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=unsubscribe>
List-Id: Anti-Spam Research Group - IRTF <asrg.ietf.org>
List-Post: <mailto:asrg@ietf.org>
List-Help: <mailto:asrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/asrg/>
Date: Fri, 06 Feb 2004 15:13:02 -0600
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


Here's how the pay2send.com Advenge SMTP daemon deals with Brett
Watson's scenario:

Chris knows at least one of Bob's "magic phrases" which he
used to get on Bob's whitelist in the first place.

The Aardvark article sending service allows Chris to write
an introduction to the article (all article sending services
I have used have this facility) and Chris includes the
magic phrase ("transferrable mnemonic capability key" for the security
theorists) in the introduction.

Bob receives the article and the introduction in one e-mail, which
passes the filter since the introduction includes the magic phrase.

Bob also receives a "magic phrase match report" including non-mnemonic
one-time-use capability keys for

	* adding whatever the return address on aardvark press forwarded 
articles is to his whitelist

	* adding the aardvark outgoing SMTP host to his whitelist

	* invalidating the magic key used (in case Chris is out
	   of control).

Unless Bob uses one of the whitelist extension buttons, he will not
receive further mail from Aardvark even if they send him some. (unless
it quotes Chris's introduction again.)


As a special case, consider:

	(1) Chris has registered a RAPNAP preference list,
which for ASRG purposes is a per-sender RMX list

	(2) Aardvark forwarding uses the forwarding requestor's
e-mail address as the source address for the forwarded article
(Amazon.com apparently currently does this with book reccommendations)

If 1 and 2 are both true, Chris will receive a challenge concerning
mail from him originating at a new peer and must approve Aardvark's
peer before the Advenge SMTPD server will even accept Chris's return
address from Aardvark's server, so Chris will have to do that, which
will moot the magic phrase being in the introduction, because the
message will have gotten approved based on Chris being whitelisted
so the magic phrase inspection will not be required.  Chris can take
Aardvark's IP out of his RAPNAP server list afterwards, or leave it
there and trust that Aardvark isn't going to actionably misrepresent
next quarter's Aardvark catalog as a personal message from Chris.

If 2 but not 1, mail spoofed as From Chris has the benefit of Chris's
whitelisting status.


Special case 2:

lemma (2) is true, but Chris has registered a public key with the server
infrastructure rather than a Peer Network Address list.
In order to get past the Advenge filtering system, Chris has to
public-key-sign the text he pastes into the introductory text control
in Aardvark's article forwarding form.


Brett Watson wrote:
> Za'mbori, Zolta'n wrote:
> 
>>If Aardvarks.example.com will be the MAIL FROM than MTA doing white-list
>>filtering at the SMTP level will refuse this email even the white-list
>>contains the email address of Bob.
> 
> 
> So our scenario goes like this: Chris wants publisher Aardvarks to send an 
> article to Bob. Chris is in Bob's whitelist, but Aarvarks is not. Should the 
> message from Aardvarks be delivered to Bob on the basis that it was requested 
> by Chris, although not sent *by* him as such? In other words, should the 
> whitelisting be transferrable? If Bob has authorised Chris to send mail to 
> him, can Chris then share that authorisation with Aardvarks? If so, is the 
> authorisation a one-off thing, or a permanent thing? And can Aardvarks then 
> share the authority with its "business partners"?
> 
> You can probably see where this is going. It's the situation that we have now 
> with email addresses. I can create a single-use email address (like the one 
> I've used for subscription to this list), but I can't control its 
> dissemination and subsequent use. The best I can do is retire an address when 
> it becomes abused beyond its worth. If I had a strong LMAP-like means of 
> verifying sender addresses, then I could restrict incoming addresses to use 
> by particular senders, but the senders could not easily share their authority 
> to send. Anything more subtle than those two policies will be difficult to 
> implement. Not impossible, but certainly complex.
> 
> So let us assume that Chris is NOT authorised to share his mail-sending 
> authority with third parties. Acting on Chris' request, Aardvarks.example.com 
> finds itself unable to send mail to Bob, because Bob's mail policies reject 
> mail from unknown parties. What can Aardvarks do about this? One possibility 
> is to mail the article to Chris instead, saying, "we were unable to deliver 
> this article to Bob as you requested. Please forward it to him with our 
> compliments, and suggest that he add Aardvarks to his mail white-list if he 
> wishes to receive forwarded articles from us more conveniently in future."

I agree that the above policy is a reasonable one for Aardvarks to follow.



> If Chris is unable to forward the article to Bob himself, then he never had 
> the authority to request the mailing in the first place.

"Introductory texts" on article forwarding systems are a perfect place 
to insert "classical passwords."


_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg