Re: Sender mailbox identities

On Sat, Mar 26, 2005 at 10:41:11AM +0000, Brian Candler wrote:
> One alternative I thought of was to present instead a *hash* of the user ID
> and message store ID, and call it a "sender fingerprint":
> 
> from unknown [f8:1e:26:80:96:c9:54:e4:60:8f:32:bd:78:ee:5d:53] says 192.0.2.2
> 
> (that's an MD5 hash of "[email protected]\0example.net")
> 
> Once you've received a particular message and believe it's genuine, e.g. by
> successfully sending a reply, you could tell your MUA to remember the
> fingerprint and associate it with an identity (e.g. the address you replied
> to) and display that instead in future. These fingerprints could be included
> on business cards, letterheads etc.

A problem I realised with this, is that one message store may be shared
between several people sending you mail, and therefore the identity of the
message store account may not uniquely identify the person sending you the
mail.

I can think of two common cases where this may happen:

(1) You have an incoming SMTP MX gateway to allow you to receive mail from
the rest of the Internet (that is, those who are not im2000-capable).

In this case you would point MX records for your own domain at a gateway
message store; it will receive the incoming mail, store it, and then start
sending notifications to your receipt notification agent. They will probably
look like:

   from smtpgateway on example.net says 192.0.2.2

i.e. *all* non-IM2000 mails will appear to originate from the same message
store in the notification messages you see.

(2) If you are a business running an internal SMTP mail system (let's say a
Microsoft Exchange server for the sake of argument), and you configure it to
send all outgoing mail via your own IM2000 SMTP shim, or via your ISPs
mailstore shim authenticated using SMTP AUTH and a fixed username and
password. In that case, it's probable that all outgoing mail from everyone
in your organisation will appear to originate from a single IM2000 mail
store.

So actually, the sender mailstore ID is not usefully tied to a single
individual.

I'm coming to the conclusion that although IM2000's separation of sender
identities and recipient identities has an appeal to those who like the
world to be orthogonal, it's not actually useful to real world users. For
them, it would be better, if the sender mailstore ID and the recipient
mailstore ID (i.e. E-mail address) were the *same* thing. What use is it to
receive a mail from account 'brian123' on message store 'foo.com', if that
doesn't tell you reliably what address to send a response to?

I had another thought. Mailstores in Jonathan de Boyne Pollard's spec are,
intentionally, write-only entities. However, there is another real-world use
for message stores, and that is for server-based "folders", where you can
organise and store mail for future retrieval. This is the service you get
today (a) from many webmail clients, and (b) with IMAP message stores and
clients.

The IMAP protocol is an utter mess, and if the IM2000 protocol could
supercede it, that would be a big plus in its own right.

Imagine, then, a world where the IM2000 message store is divided into
folders.

- if you authenticate to your message store, you can read and write messages
in any folder

- you send mail by putting a message into a folder of your choice (say
"Outbox"), and then starting sending notifications to the recipients that
this message is available for retrieval.

These would be very similar to IM2000 notifications, except the key you use
to access the message is the mailbox *E-mail address* plus a cookie.
Therefore, the notifications contain an authenticated, phishing-proof sender
identity (since if you forge a notification from '[email protected]',
say, then you will contact paypal.com's servers to try to retrieve the
message, and it won't be there)

- any message which is stored in one of your folders could be *forwarded* to
another person using the same mechanism. That is, let's say you receive a
message from your boss, and you file it in folder "Important". You can still
'send' this message directly on just by telling your mail store to send
notifications to the recipients you want to fetch a copy. No extra copy need
be created on the message store.

- as well as these private-read, private-write folders, you could have:
  - write/read to other authenticated users on the system (= shared mailbox)
  - private-write, public-read  ( = blog)
  - private-read, public-write  ( = drop box?)
  - public-write, public-read   ( = mailing list)

But I do think the public-write, public-read mailing list concept in IM2000
is fatally flawed. Anyone who has run an FTP server with a public read/write
'incoming' directory will know what I mean: it will soon be discovered and
used for uploading warez and porn.

I used to work at a large ISP, which allowed signups for free Internet
accounts with POP3/webmail mailboxes. Those mailboxes had small quotas (10MB
each). However, once people on the Internet discovered this service, they
wrote scripts to sign up in bulk for accounts; they broke their CD ISO
images into 10MB chunks, mailed them to each of the accounts, and then
distributed the POP3 usernames and passwords to their friends. Hey presto,
we were unintentionally providing a free file distribution service.

IM2000 mailing lists make this sort of abuse far too easy, and the reason is
(in my opinion) that the senders are completely unauthenticated and
therefore anonymous.

So I think to make mailing lists work in the IM2000 world, they have to come
from authenticated senders, which means a two-step posting process: the
poster submits the message to the mailing list as a *personal* mail, and
then the mailing list copies it to a local message store.

That is: if I am [email protected], sending to [email protected], then:

1. I put the message in my own message store (outbox)
2. It sends out rcpt notifications to [email protected]
3. The list robot downloads the mail from my message store, and inserts it
   into its own message store, from where people can read it.

Using this approach, the sender is authenticated, and can therefore be
blacklisted. Greylisting (= moderation) can be used for senders who have not
been seen before.

One thing I don't think J de BP addresses is that mailing list archives are
not particularly usable unless they are searchable; they also benefit from
giving a threaded view. If IM2000 message stores were able to do these
things server-side, then that again would make them an excellent replacement
for IMAP.

Finally, if a message store is going to contain your (received) mail
folders, then why not have an 'INBOX' folder? When someone sends you a
receipt notification, and the MUA logs in, it could trigger a process
whereby the message store itself fetches the outstanding messages and puts
them in your INBOX. The advantage would be more orthogonal access to your
mailbox; receiving new mail would no longer be a 'special case' for the MUA
to deal with. It would also permit filtering to be done server-side (e.g.
with Sieve), which IMO is where it belongs; if you retrieve your mail from
several different places, you don't want to be applying different filter
rules each time, so I think the filter ruleset belongs with the mailbox, not
the client.

Regards,

Brian.