Forwarding in im2000

As a user of one of these "E-mail address for life" forwarding services
(pobox.com), I was wondering how these type of services might work in the
im2000 world.

I can see at least five distinct alternatives for what happens when someone
sends mail to [email protected], which in today's world I want to be
forwarded to [email protected].

0. Nothing is forwarded at all; I configure my MUA to subscribe to a Receipt
Notification Agent service at pobox.com. In today's world, that would be
equivalent to pobox.com providing me with a POP3 mailbox instead of a
forwarding service.

1. An RNASP notification arrives at the pobox.com server, which replies with
a message saying "not here: resend to [email protected] instead". The sender
then starts sending notifies to that new address too. (Note: potentially
could send back a list of more than 1 address to forward to). I don't see
anything in the spec which allows that.

2. An RNASP notification arrives at the pobox.com server, which modifies it
and resends it to the new receipient(s) notification agent(s). This would
happen for each RNASP packet coming in; no state would be kept.

3. An RNASP notification arrives at the pobox.com server, which then
downloads the message from the sender's message store using MSRAP, and then
sends it on as a fresh message; that is, sending out RNASP packets to the
new recipient(s) notification agent(s), who would then retrieve the message
from the pobox.com server. Note that the message itself has actually gone
through a layer of forwarding here, so this seems against the spirit of
im2000 (especially without any Received: headers for debugging this sort of
stuff).

4. There's another option, which is for the sender to lookup
b.candler._at.pobox.com in the DNS, and find one or more new E-mail
addresses. It would then have to lookup in the DNS to find the RNASP
server(s) for those addresses. It's not sufficient to list *just* the RNASP
server which you want to send to, because that server will have a mailbox
called "[email protected]" but won't know that incoming notifications for
"[email protected]" should be associated to that mailbox (unless it is
configured to do so, which means forwarding won't work unless you configure
it at the receiver as well as in the DNS)

Mechanisms 1-4 could apply to traditional .forward files. And each of these
mechanisms could be used to set up ad-hoc mailing lists which
*break* the im2000 model of how mailing lists "should" work (receiver pulls,
rather than sender notifies).

I guess the "right answer" is option 0; and the im2000 architecture
obsoletes the concept of a .forward file. A Unix user has no local mailbox,
but just configures their MUA with a list of receipt notification agent
accounts, and pulls messages from there.

But forwarding is used in other cases too. What about role contact
addresses, like <[email protected]>? In the current world, I may have this
set up to forward to several members of staff, or I may have a shared
mailbox which several members of staff all have read and delete access to.

Now, if a potential customer wants to send a mail to <[email protected]>,
the last thing they want to have to do is configure their MUA to subscribe
to a write-only mailing list on the example.com server. Clearly, this has to
go out like a personal mail: the message goes into the sender's message
store, and a notification goes to <[email protected]>

Now, what happens next? One option is that notifications which arrive for
[email protected] are re-sent to [email protected] and [email protected]
(like option 2 above). That would be the equivalent of 'shared folder
access'; the sending message store will believe that the message has been
sent to <[email protected]>, but it will end up seeing un-pin requests from
<[email protected]> and/or <[email protected]>. Since they both have a
copy of the same opaque key, I guess the first one to un-pin the message
wins. That makes sense I guess; freda has dealt with the message, bob
doesn't need to see it.

Another option is like option 3, where [email protected] is a robot message
store which pulls down the message from the sender's message store, and
starts resending notifications to [email protected] and
[email protected]. This is attractive in its simplicity, but blessing
this way of operation is likely to see people setting up mailing lists in
this way, violating the way that im2000 message stores are "supposed" to
operate.

Has this ground been covered before? Any thoughts - especially from Mr. de
Boyne Pollard if he's around?

Cheers,

Brian.