Sender mailbox identities

[Brian Candler]

Just one other thought for now.

In IM2000, when you receive an incoming message notification in your MUA, it
shows a tuple of <user ID, message store ID, notification source address>:
e.g. at
http://homepages.tesco.net./~J.deBoynePollard/Proposals/IM2000/CaseStudies/lucy-reading.html
we have an incoming notification that says

from toby on example.net. says 192.0.2.2
^^^^ ^^^^^^^^^^^^ ^^^^^^^^^

The tuple <toby, example.net> is what people are likely to associate as an
"E-mail address", even though the new architecture specifically divorces
sender message store accounts from E-mail addresses for receiving mail.

There is also the likelihood that operators of VISP services will include
domains within message store user IDs. e.g.

from ***@smallbusiness.com on smallbusiness.com says 192.0.2.2
^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^

(where 'smallbusiness.com' has SRV records pointing to example.net's message
store); or else

from ***@smallbusiness.com on example.net says 192.0.2.2
^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^

Putting the mailbox ID in that form is attractive because it gives a
separate user ID namespace for each virtual domain. I think it's almost
certain that this practice would occur, but then I think the typical
end-user is unlikely to be able to interpret this information in a way to
avoid phishing attacks, especially given that receipt notifications can
identify the message store by IP address:port and not by domain. For
example:

from ***@paypal.com on spammerdomain.com says 64.202.167.129

or worse,

from ***@paypal.com on [64.202.167.129:1234] says 64.202.167.129

I wonder here if we are actually doing a *disservice* to most users by
presenting the information in this way. That information is hardly any
better than what we have now, which is a combination of
Return-Path:<***@paypal.com> and Received: from 64.202.167.129

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 "***@smallbusiness.com\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.

Such fingerprints might also be useful for blacklist lookups, where existing
RBL mechanisms don't easily support a lookup of these tuples, and might help
some privacy concerns when looking them up.

The other alternative I thought of was to publish, in the DNS, bindings
between E-mail addresses and sender accounts. For example, if you receive a
mail purporting to be From: ***@pobox.com, you would do a lookup on
b.candler._at.pobox.com
and find a list of <message store, account ID> tuples that I use to send
mail. If you find a list but the originating message store account isn't
among them, then you know the message is forged.

Unfortunately, you won't know this until you've downloaded at least the
headers of the message from the sender's message store, which gives
information to spammers about your account[1]

Also, either mechanism needs to go in at day one, if im2000 is going to
benefit from it. Otherwise, a completely separate way of validating message
senders, such as DomainKeys, is going to be essential.

Regards,

Brian.

[1] In which case, it might be better to include the purported sender in the
notification message; or else to make message store IDs officially look like
E-mail addresses and always be bound to <message store, account ID> via the
DNS.

At the end of the day, the user is not interested in "which message store
did this message originate from", but
- did this originate from someone I already know (if so who?); and/or
- if I send a reply to this message, will it go to the same person?

[Brian Candler]

Post by Brian Candler
One alternative I thought of was to present instead a *hash* of the user ID
from unknown [f8:1e:26:80:96:c9:54:e4:60:8f:32:bd:78:ee:5d:53] says 192.0.2.2
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 '***@paypal.com',
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 ***@example.net, sending to ***@lists.ietf.org, then:

1. I put the message in my own message store (outbox)
2. It sends out rcpt notifications to ***@lists.ietf.org
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.