ietf-asrg
[Top] [All Lists]

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

2004-02-06 15:17:31


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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg